Repository navigation
Replace the single Suspense fallback with per-route loading skeletons #36
Description
Problem
src/App.tsx lazy-loads every route but renders one bare Fallback() component as the shared Suspense fallback for all of them. While a route's chunk loads, users see the same minimal placeholder regardless of whether they are opening a contract dashboard, an event table, or the graph view, which reads as a blank/janky transition on a data-dense app.
What needs to be done
- Create route-appropriate skeleton components that mirror the layout of the destination page (for example a table skeleton for list views, a card skeleton for the contract dashboard).
- Wrap the heavier routes in their own
Suspenseboundaries with the matching skeleton, rather than relying on the single top-level fallback. - Keep a sensible default fallback for lightweight routes.
- Ensure skeletons are theme-aware and do not cause layout shift when the real content loads.
Files
src/App.tsx- new skeleton components under
src/components/
Acceptance deliverables
- Heavier routes show a layout-matching skeleton while loading, not the bare fallback.
- No layout shift when real content replaces the skeleton.
- All CI checks pass; the change cannot be merged until CI is green.
Tests to pass
- Test: a lazily loaded route renders its skeleton while its chunk/suspense is pending.
- Existing routing tests continue to pass.
Activity
vickman787 commentedon Aug 18, 2026
Hi team,
I would love to tackle Issue #36. Relying on a single top-level Suspense fallback often creates jarring, unpolished transitions in data-heavy applications. I have extensive experience optimizing React rendering lifecycles and implementing theme-aware, exact-dimension skeleton screens that prevent cumulative layout shift (CLS).
Here is my technical plan for fulfilling the acceptance criteria:
Proposed Architecture
1. Create Route-Specific Skeleton Components
I will build modular, theme-aware skeleton components under src/components/ that mirror the exact layouts of the heavier destination pages.
TableSkeleton: For list/event views. This will include a mock header row and several animated placeholder rows.
DashboardSkeleton: For the contract dashboard, featuring card-like block placeholders.
GraphSkeleton: For the graph view, matching the dimensions of the chart container.
Theme Awareness: I will utilize the existing design system or CSS variables/Tailwind classes to ensure the skeletons respond correctly to light/dark modes (e.g., using subtle pulsing opacity animations that match the background surface colors).
2. Implement Per-Route Suspense Boundaries
I will refactor src/App.tsx (or the routing configuration file) to push the Suspense boundaries down the component tree.
Heavier lazy-loaded routes (like the Dashboard, Graph, and List views) will be individually wrapped in their own blocks, passing the corresponding route-specific skeleton as the fallback prop.
This ensures that when a user navigates to a complex view, the skeleton layout immediately renders while the chunk loads, significantly improving the perceived loading speed.
3. Retain the Default Global Fallback
The existing bare component will be preserved at the top level of the routing tree. This will serve as a catch-all for lightweight routes or minor components where building a dedicated skeleton is overkill.
4. Zero Layout Shift (CLS) Guarantee
To prevent layout shift when the real content replaces the skeleton:
I will ensure all skeletons use the same container structure, padding, margins, and explicit min-height/height properties as their target components.
This guarantees that the page layout remains entirely static when the React Suspense boundary resolves and swaps the skeleton for the actual route content.
Testing Strategy
I will update the test suite to guarantee all CI checks remain green:
New Route Tests: I will use React Testing Library to simulate a pending lazy load on a heavy route, asserting that the specific skeleton component is mounted and visible in the DOM.
Regression Tests: I will verify that the existing routing tests continue to pass and that the global fallback is still correctly utilized for generic routes.
Implementation Milestones
Phase 1: Analyze the DOM structure of the heaviest routes and build the TableSkeleton, DashboardSkeleton, and GraphSkeleton components to match.
Phase 2: Refactor src/App.tsx to wrap the heavy routes in localized boundaries.
Phase 3: Fine-tune the skeleton dimensions and CSS styles to eliminate any layout shift during the component swap.
Phase 4: Write the new Suspense UI tests and run a full manual QA and CI check.
Why me: I have a strong track record of building accessible, highly responsive Web3 frontends. I know how to structure React Suspense boundaries for optimal code-splitting, and I am meticulous about preventing layout jank in data-dense applications.
Please let me know if you have a specific library in use for animations (like Framer Motion or just pure CSS), or if I should go ahead and open a draft PR to get started!
Tips before you submit:
Performance Metrics: Using terms like "Perceived Performance" and "Cumulative Layout Shift (CLS)" signals to the maintainers that you understand the UX and web-vitals reasoning behind this architectural change.
React Suspense: Mentioning pushing the Suspense boundaries "down the component tree" shows a solid architectural understanding of how React handles lazy loading and error/loading boundaries.
Xaxxoo commentedon Aug 18, 2026
hi can I take up on this issue ?
grantfox-oss commentedon Aug 18, 2026
🦊 GrantFox — @Xaxxoo has been assigned to this issue as part of the Third Campaign campaign!
Next steps:
Closes #36)Good luck! Track your progress on GrantFox.
grantfox-oss commentedon Aug 19, 2026
🎉 This issue has been marked as completed on GrantFox as part of the Third Campaign campaign!
@Xaxxoo's PR #41 was approved and merged by @priscaenoch.
🏆 @Xaxxoo: You earned 40 FoxPoints for this contribution! Your current tier: Builder (1,225 total points). Track your full progress on GrantFox.
👏 Great work, @Xaxxoo! Keep contributing to octraban.