Hem was one ~33-query render behind a single fallback: the greeting waited
for the slowest worklist scan, and the request also paid a sequential
bank_file_imports read after the batch, a second scan of the suggested
matches (getWorklistCounts counted the same 200 rows the pane listed) and
an awaited stale-dismissal delete on the read path.
- page.tsx awaits only what the greeting shell and the redirects need
(settings, profile, agent profile, the Skatteverket flag); the notice
line, the setup checklist and the Att göra + Fortsätt panes are async
server components behind their own Suspense (hem-sections.tsx). RSC
streaming applies to client navigations too, so the greeting paints
first on every visit and each block fills in as its queries land.
- DashboardContent becomes the shell with three slots; HemNotices keeps
the one client-side action (the wrong-account sign-out); HemSkeletons
are the two fallbacks.
- getWorklistCounts accepts the suggested matches the caller is already
fetching (a promise, so it stays parallel); listSuggestedMatches runs
once at the scan cap and the pane shows the first five.
- countInboxDocuments runs its id chunks in one wave instead of N
sequential round trips.
- getCompanyNotices takes deferReap; Hem passes Next's after() so the
stale-dismissal delete runs after the response.
- bank_file_imports joins the checklist section's batch.
Tests: worklist aggregate (precomputed matches skip the rescan), notices
aggregate (deferReap receives the reap; the delete does not run inline
and runs when the task does).
Co-authored-by: Jakob Wennberg <311770904+jakobwennberg-oss@users.noreply.github.com>
Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
Jakob Wennberg
a8980a3a41