Build a multi-panel dashboard with parallel routes instead of client-side tab state

You are structuring a multi-panel dashboard using parallel routes, the @slotName folder convention, under a shared layout.tsx, instead of one page component that fetches everything up front and manages an "active panel" with client-side tab state.

DASHBOARD PANELS
a revenue trend chart (last 90 days), a support-ticket queue list, and a team-utilization heatmap

NAVIGATION REQUIREMENTS
The support-ticket queue needs its own filter state reflected in the URL and shareable via link; the other two panels don't need deep-linking

CURRENT IMPLEMENTATION
One DashboardPage component fetches all three datasets in parallel with Promise.all, then renders all three children behind a single shared loading boolean — nothing is actually gated by tab state, but one slow query still blocks the whole page.

ROUTE BASE
/dashboard

REQUIREMENTS
Create one @slotName folder per independent panel directly under the shared layout, each with its own page.tsx that fetches only that panel's data — never a parent component that fetches everything up front and distributes it down as props to children that could have fetched it themselves. Give each slot its own loading.tsx so a slow panel shows its own skeleton and streams in on its own schedule; a slow analytics query must never block a fast activity feed from rendering just because they happen to share a layout. Give each slot its own error.tsx too, so a failure in one panel's data fetch renders an inline error scoped to that panel, not a full-page crash that takes every other panel down with it. Add a default.tsx to every slot, returning either null or a sensible fallback view. This matters for two distinct reasons: on a hard navigation or full page reload, where the current URL only matches one slot's most specific route, Next.js needs default.tsx to know what to render for every other slot that has no matching segment in that URL — without it, that mismatch produces a 404 for the entire layout, not just for the one unmatched slot. On a soft, client-side navigation, Next.js instead preserves whichever content an unmatched slot was already showing rather than falling back to default.tsx at all, which is a real behavioral difference worth confirming your panels actually handle correctly rather than assuming either mode covers both cases. The layout.tsx itself receives all slots as named props alongside children and is responsible only for arranging them into the visual grid — it does not fetch data of its own, and any data genuinely needed by the layout chrome, such as a page title or a global filter bar, should be treated as its own concern rather than folded into whichever slot happens to load fastest.

OUTPUT FORMAT
The folder structure as a tree, the layout.tsx showing exactly how the slots are composed as props, and one paragraph walking through what happens on a hard refresh versus a soft in-app navigation when only one slot's URL segment is present in the current path.