reactive-dashboard-performance

Performance Patterns (Linear, Vercel, Notion-grade)

1. Skeleton-First Loading

- Render skeleton immediately (0ms perceived load)

- Stream in data progressively

- Never show spinners for <200ms loads

1. Aggressive Caching

- React Query with staleTime: 5min, cacheTime: 30min

- Optimistic updates for mutations

- Prefetch on hover/mount

1. Code Splitting

- Route-based splitting (Next.js automatic)

- Component-level lazy() for heavy widgets

- Preload critical paths

1. Memoization Strategy

- useMemo for expensive computations

- React.memo for pure components

- useCallback for stable references

Testing Reactive Dashboards

1. Mock Strategy

- Mock at service boundary (React Query, analytics)

- Never mock UI components (test real DOM)

- Use MSW for API mocking when possible

1. 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

- Timeouts mean: missing mock, wrong query, or component not rendering

- Use screen.debug() to see actual DOM

- Check console for unmocked errors

1. Test Wrapper Pattern

```typescript

const TestProviders = ({ children }) => (

{children}

);

```

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

Integration Test Timeouts

1. Check what's actually rendering

```typescript

render();

screen.debug(); // See actual DOM

```

1. Find unmocked dependencies

- Check console for "not a function" errors

- Look for network requests in test output

- Verify all contexts are provided

1. Fix async queries

- Use findBy instead of getBy

- Increase timeout if needed: waitFor(() => {...}, { timeout: 3000 })

- Mock React Query properly

1. Simplify component tree

- Test widgets individually first

- Add full integration tests last

- Use data-testid for complex queries

Dashboard Load Budget

| Phase | Target |

|-------|--------|

| Skeleton render | 0-16ms (1 frame) |

| First data paint | <100ms |

| Full interactive | <200ms |

| Lazy widgets | <500ms |

React Query Config

```typescript

const queryClient = new QueryClient({

defaultOptions: {

queries: {

staleTime: 5 60 1000, // 5min

cacheTime: 30 60 1000, // 30min

refetchOnWindowFocus: false,

refetchOnMount: false,

retry: 1,

},

},

});

```

Skeleton Pattern

```typescript

function Dashboard() {

const { data, isLoading } = useQuery('dashboard', fetchDashboard);

// Show skeleton immediately, no loading check

return (

);

}

```

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.