yiekheng
9a4072129a
The 'switching is laggy with many accounts' report — root cause is that both /page.tsx and /users/page.tsx are Server Components that block on the API fetch before sending any HTML. During the wait, the previous route stays frozen (no spinner, no feedback) — the user perceives a 'lag' that grows with row count. App Router's loading.tsx convention solves this: Next.js renders it INSTANTLY on navigation, then streams in the real RSC tree once the data fetch resolves. The skeleton matches the shape of the real shell + a few placeholder rows so the swap is layout-stable. Files: - web/components/table-skeleton.tsx — shared skeleton (PageHead + N rows) - web/app/loading.tsx — used for / - web/app/users/loading.tsx — used for /users If row counts keep growing past a few hundred and the table itself becomes the bottleneck (vs the network fetch this addresses), the next step is pagination: accept ?limit=&offset= on /acc/ and /user/ in cm_api.py and add a 'Load more' button (or a virtual list) at the table-component layer.
6 lines
154 B
TypeScript
6 lines
154 B
TypeScript
import TableSkeleton from "@/components/table-skeleton";
|
|
|
|
export default function Loading() {
|
|
return <TableSkeleton eyebrow="Table" title="Users" />;
|
|
}
|