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)

1. Skeleton-First Loading
2. Render skeleton immediately (0ms perceived load)
3. Stream in data progressively

4. Never show spinners for <200ms loads

5. Aggressive Caching

6. React Query with staleTime: 5min, cacheTime: 30min
7. Optimistic updates for mutations

8. Prefetch on hover/mount

9. Code Splitting

10. Route-based splitting (Next.js automatic)
11. Component-level lazy() for heavy widgets

12. Preload critical paths

13. Memoization Strategy

14. useMemo for expensive computations
15. React.memo for pure components
16. useCallback for stable references

Testing Reactive Dashboards

1. Mock Strategy
2. Mock at service boundary (React Query, analytics)
3. Never mock UI components (test real DOM)

4. Use MSW for API mocking when possible

5. Async Handling
   ```typescript
   // WRONG - races with React
   render();
   const element = screen.getByText('Welcome');

// RIGHT - waits for async resolution
render();
const element = await screen.findByText('Welcome');
```

1. Timeout Debugging
2. Timeouts mean: missing mock, wrong query, or component not rendering
3. Use screen.debug() to see actual DOM

4. Check console for unmocked errors

5. Test Wrapper Pattern
   typescript 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

1. Check what's actually rendering
   typescript render(<Component />); screen.debug(); // See actual DOM

2. Find unmocked dependencies

3. Check console for "not a function" errors
4. Look for network requests in test output

5. Verify all contexts are provided

6. Fix async queries

7. Use findBy instead of getBy
8. Increase timeout if needed: waitFor(() => {...}, { timeout: 3000 })

9. Mock React Query properly

10. Simplify component tree

11. Test widgets individually first
12. Add full integration tests last
13. Use data-testid for complex queries

Performance Optimization

Dashboard Load Budget

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

1. Spinners for fast loads - Use skeletons instead
2. Unmemoized expensive computations - Wrap in useMemo
3. Testing implementation details - Test user behavior
4. Mocking too much - Mock at boundaries only
5. Synchronous test expectations - Everything is async

When debugging test timeouts, ALWAYS start with screen.debug() to see what actually rendered.