mcpbeat Sign in

Reactive Dashboard Performance Agent Skill

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.

1k tokens
context cost
the whole folder, loaded on every use
1
files
instructions only
0
copies elsewhere
how many repositories repackaged it
177
stars on the repo
on the repository, not the skill itself

Install

one command, takes just this skill from the repository
npx skills add https://github.com/curiositech/some_claude_skills --skill reactive-dashboard-performance

The instruction itself

12 sections, as written by the author

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 &lt;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 | &lt;100ms |

| Full interactive | &lt;200ms |

| Lazy widgets | &lt;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.

Other skills for the same job

different authors, same section of the catalogue
Seaborn
by ComeOnOliver
×3

Statistical visualization. Scatter, box, violin, heatmaps, pair plots, regression, correlation matrices, KDE, faceted plots, for exploratory analysis and publication figures.

57k tokens
Ab Test Setup
by lingxling
×1

Structured guide for setting up A/B tests with mandatory gates for hypothesis, metrics, and execution readiness.

2k tokens
Dbt Transformation Patterns
by ComeOnOliver
×1

Master dbt (data build tool) for analytics engineering with model organization, testing, documentation, and incremental strategies. Use when building data transformations, creating data models, or implementing analytics engineering best practices.

6k tokens
Dbt Transformation Patterns
by ComeOnOliver
×1

Master dbt (data build tool) for analytics engineering with model organization, testing, documentation, and incremental strategies. Use when building data transformations, creating data models, or implementing analytics engineering best practices.

7k tokens
Keeper Stress Analysis
by ClickHouse
vendor

Analyze ClickHouse Keeper stress-test results from play.clickhouse.com / keeper_stress_tests data warehouse. Use whenever the user asks about Keeper performance, validates Keeper PRs against stress dashboards, investigates regressions or improvements in Keeper nightlies, asks about specific date windows / SHAs / PR-sets in Keeper stress tests, wants per-PR or window-vs-window comparisons, asks "did this PR break Keeper", asks "what changed in Keeper between dates", or wants a summary report of Keeper stress runs. Triggers on terms like "keeper stress", "keeper PR", "keeper p99", "keeper memory", "keeper rps", "keeper nightly", "keeper-stress-tests", "keeper validation", "keeper regression", or any question referencing the keeper-stress Grafana dashboard. ALWAYS prefer this skill over re-deriving the workflow from scratch — it captures hard-learned lessons about cgroup-vs-Keeper memory, bench-harness confounds, noise floors, and per-PR attribution limits.

40k tokens scripts
Dbt Transformation Patterns
by wshobson

Master dbt (data build tool) for analytics engineering with model organization, testing, documentation, and incremental strategies. Use when building data transformations, creating data models, or implementing analytics engineering best practices.

3k tokens
Dashboard Testing
by microsoft
vendor

Guide for writing tests for the Aspire Dashboard. Use this when asked to create, modify, or debug dashboard unit tests or Blazor component tests.

4k tokens
Canvas2d Data Visualization
by openai
vendor

Render data visualizations with Canvas2D. Use when the visualization needs high mark counts, fast redraws, immediate-mode rendering, custom hit testing, or a hybrid Canvas plus SVG or HTML architecture.

10k tokens

How to use it

Copy the folder

Take curiositech/reactive-dashboard-performance from the repository into ~/.claude/skills for personal use, or into .claude/skills inside a project.

Check the name does not clash

The agent identifies a skill by the name field in its header. Two skills with the same name cannot sit side by side — one of them will be ignored.