
reactive-dashboard-performance
by erichowens
Claude skills that make my life easier.
SKILL.md
name: reactive-dashboard-performance description: Expert in building blazing-fast reactive dashboards with comprehensive testing. Masters React performance patterns, testing strategies for async components, and real-world patterns from Linear, Vercel, Notion. version: "1.0.0" category: Frontend Development tags:
- react
- performance
- testing
- dashboard
- optimization allowed-tools:
- Read
- Write
- Edit
- Bash
- Grep
- Glob triggers:
- "dashboard performance"
- "slow tests"
- "reactive testing"
- "integration tests timeout"
- "dashboard optimization"
Reactive Dashboard Performance
Expert in building production-grade reactive dashboards that load in <100ms and have comprehensive test coverage.
Core Expertise
Performance Patterns (Linear, Vercel, Notion-grade)
-
Skeleton-First Loading
- Render skeleton immediately (0ms perceived load)
- Stream in data progressively
- Never show spinners for <200ms loads
-
Aggressive Caching
- React Query with staleTime: 5min, cacheTime: 30min
- Optimistic updates for mutations
- Prefetch on hover/mount
-
Code Splitting
- Route-based splitting (Next.js automatic)
- Component-level lazy() for heavy widgets
- Preload critical paths
-
Memoization Strategy
- useMemo for expensive computations
- React.memo for pure components
- useCallback for stable references
Testing Reactive Dashboards
-
Mock Strategy
- Mock at service boundary (React Query, analytics)
- Never mock UI components (test real DOM)
- Use MSW for API mocking when possible
-
Async Handling
// WRONG - races with React render(<Dashboard />); const element = screen.getByText('Welcome'); // RIGHT - waits for async resolution render(<Dashboard />); const element = await screen.findByText('Welcome'); -
Timeout Debugging
- Timeouts mean: missing mock, wrong query, or component not rendering
- Use screen.debug() to see actual DOM
- Check console for unmocked errors
-
Test Wrapper Pattern
const TestProviders = ({ children }) => ( <QueryClientProvider client={testQueryClient}> <AuthProvider> {children} </AuthProvider> </QueryClientProvider> );
Real-World Examples
- Linear Dashboard: Skeleton → Stale data → Fresh data (perceived <50ms)
- Vercel Dashboard: Prefetch on nav hover, optimistic deploys
- Notion Pages: Infinite cache, local-first, sync in background
Diagnostic Protocol
Integration Test Timeouts
-
Check what's actually rendering
render(<Component />); screen.debug(); // See actual DOM -
Find unmocked dependencies
- Check console for "not a function" errors
- Look for network requests in test output
- Verify all contexts are provided
-
Fix async queries
- Use findBy* instead of getBy*
- Increase timeout if needed:
waitFor(() => {...}, { timeout: 3000 }) - Mock React Query properly
-
Simplify component tree
- Test widgets individually first
- Add full integration tests last
- Use data-testid for complex queries
Performance Optimization
Dashboard Load Budget
| Phase | Target |
|---|---|
| Skeleton render | 0-16ms (1 frame) |
| First data paint | <100ms |
| Full interactive | <200ms |
| Lazy widgets | <500ms |
React Query Config
const queryClient = new QueryClient({
defaultOptions: {
queries: {
staleTime: 5 * 60 * 1000, // 5min
cacheTime: 30 * 60 * 1000, // 30min
refetchOnWindowFocus: false,
refetchOnMount: false,
retry: 1,
},
},
});
Skeleton Pattern
function Dashboard() {
const { data, isLoading } = useQuery('dashboard', fetchDashboard);
// Show skeleton immediately, no loading check
return (
<div>
{data ? <RealWidget data={data} /> : <SkeletonWidget />}
</div>
);
}
Common Pitfalls
- Spinners for fast loads - Use skeletons instead
- Unmemoized expensive computations - Wrap in useMemo
- Testing implementation details - Test user behavior
- Mocking too much - Mock at boundaries only
- Synchronous test expectations - Everything is async
When debugging test timeouts, ALWAYS start with screen.debug() to see what actually rendered.
Score
Total Score
Based on repository quality metrics
SKILL.mdファイルが含まれている
ライセンスが設定されている
100文字以上の説明がある
GitHub Stars 100以上
3ヶ月以内に更新がある
10回以上フォークされている
オープンIssueが50未満
プログラミング言語が設定されている
1つ以上のタグが設定されている
Reviews
Reviews coming soon