Marc-André Bombeck
675c70eba8
`/` runs its reads server-side and hands them to TanStack through a HydrationBoundary, so the first HTML already carries real tiles. React threw that away on every cold load. The app shell hydrates first and its mount answers `/api/auth/me`; the dashboard sits below `loading.tsx`, hydrates later, and its first client render therefore read an account the server never had. That disagreed with the streamed HTML, React reported #418 and re-rendered the whole page. The prefetch paid for its queries and delivered none of its paint. The account payload is now withheld from the hydration render wherever it is only rendered. `useAccountOnceMounted()` answers null until the component has mounted, which is what the server rendered, and hands the payload over on the next render. The dashboard page, the caregiver card, the getting-started checklist, the achievements tile and the unit labels read it that way. `useAuth` itself still reads the cache, because the document vault redirects off `user.modules` and a first render claiming "no account" bounces it to `/`. Two tiles disagreed without any account involved. A query reports `isLoading` true on the client's first render and false on the server, so both now gate on whether the cell holds an answer. Nothing in CI ran the shipped configuration: the suite's server turns the prefetch off so route mocks keep governing the dashboard. A second server runs it on, and one spec asserts that no hydration error is reported and that the tile node the server streamed is still the node in the DOM once the page settles. Measured over nine cold loads with the CPU throttled 4x: seven bailouts before and none after, median LCP 869 ms before and 145 ms after. FCP and the time to the first tile in the DOM are unchanged, because the streamed paint was never the problem. Keeping it was.
e2e/
End-to-end browser tests. Playwright 1.60 drives a production build of the app against a real PostgreSQL, with @axe-core/playwright for accessibility assertions. This is the heaviest test tier; CI runs it on every PR, and locally it is worth running when a change touches a UI flow.
Running
pnpm e2e
The Playwright config (../playwright.config.ts) builds the app (next build) and brings up Postgres before the specs run; setup/global-setup.ts seeds the auth + fixture state. The suite is not part of the fast local gate (typecheck / lint / test) — it surfaces at PR CI, so expect responsive/wizard/nav reworks to flag here first.
Layout
setup/—test.ts(the suite'stest+expectentry point),global-setup.ts(auth + DB seeding),test-helpers.ts(shared login + navigation helpers).utils/— fixtures such asmock-dashboard-snapshot.ts.*.spec.ts— one spec per flow: auth/login/redirect, dashboard, charts, the medication-wizard cadences (medications-wizard-*), insights generation + scroll restoration, doctor report, settings, mobile-viewport consistency, locale switch, accessibility (a11y.spec.ts), and thev1427-*regression set.
Conventions
Import test and expect from ./setup/test, never from @playwright/test — types (Page, Route, …) still come from the package. The entry point extends Playwright's test with an automatic fixture that drops route handlers and page listeners after every test, so a handler left in flight cannot fail the test it belonged to once the context closes. src/__tests__/e2e-route-cleanup-guard.test.ts enforces the import boundary.
Assert against stable data-* attributes (data-slot, data-display-step, root display attrs), not viewport-dependent visible text. Responsive sm:hidden UI changes break getByText on desktop while the underlying element is still present — anchoring on data attributes keeps the specs stable across breakpoints. See ../CLAUDE.md.