react-best-practices
mastra-ai/mastra
26 React performance and quality rules prioritized by impact, from component structure to bundle optimization.
What is react-best-practices?
A structured guide of 26 React best-practices rules organized across 9 categories and prioritized by impact. Use this skill when writing, reviewing, or refactoring React code to ensure optimal performance patterns, eliminate waterfalls, reduce bundle size, and maintain code quality.
- Eliminate waterfall async patterns with Promise.all() and parallel request strategies
- Reduce bundle size by avoiding barrel imports and deferring non-critical third-party libraries
- Optimize re-renders using lazy state initialization, startTransition, and proper Effect patterns
- Structure components with single responsibility, narrow APIs, and composition over configuration
- Enforce type safety with real type guards instead of as-casts and undefined over null
- Provide BDD testing patterns that mock only the network layer, not internal hooks or services
How to install react-best-practices
npx skills add https://github.com/mastra-ai/mastra --skill react-best-practicesHow to use react-best-practices
- 1.Identify the category of work you're doing (e.g., data fetching, re-renders, bundle optimization)
- 2.Consult the priority-ordered guidelines table to find the relevant rule category and impact level
- 3.Load the specific rule file from references/rules/ for detailed guidance, examples, and review smells
- 4.Apply the rule pattern to your code or review, checking for anti-patterns listed in the rule
- 5.Use grep on the rules directory to quickly find patterns by keyword (e.g., grep -l "Promise.all")
Use cases
- Writing new React components to follow performance-first patterns from the start
- Reviewing pull requests for performance anti-patterns like waterfalls or oversized props
- Refactoring existing components to eliminate re-render issues and improve maintainability
- Optimizing bundle size by identifying and removing barrel imports and deferring third-party code
- Setting up BDD tests that validate real client-SDK behavior without mocking internal utilities
- React developers writing or reviewing component code
- Engineering teams establishing performance standards and code-review guidelines
- Frontend architects optimizing bundle size and load-time performance
- QA and test engineers implementing BDD patterns with real SDK integration
react-best-practices FAQ
Start with Priority 1 (Eliminating Waterfalls) and Priority 2 (Bundle Size Optimization) as they have CRITICAL impact. Then move to Priority 3–5 (data fetching, re-renders, rendering) for MEDIUM-HIGH and MEDIUM impact.
No. The guidelines explicitly forbid adding useMemo or useCallback; memoization decisions should be made by developers with profiler evidence, not as a default pattern.
Always use undefined and optional ? for absence, not null. Convert external null at boundaries, and keep leaf props strict so callers own absence and fallback rendering.
Write BDD tests that drive the real @mastra/client-js + React Query stack and mock only the network layer. Never mock internal hooks, services, auth gating, or the SDK itself.
Dependent query params should be the value or undefined, never null or a fake fallback. Narrow at the caller so hooks stay strict, or guard with skipToken when the hook must accept an optional param.
Full instructions (SKILL.md)
Source of truth, from mastra-ai/mastra.
name: react-best-practices description: React performance optimization guidelines from Mastra Engineering. This skill should be used when writing, reviewing, or refactoring React code to ensure optimal performance patterns. Triggers on tasks involving React components, data fetching, bundle optimization, or performance improvements.
React Best Practices
Overview
Routing and priority guide for React performance and quality, containing 26 rules across 9 categories. Rule files hold the detailed explanations, examples, review smells, and impact metrics.
When to Apply
Reference these guidelines when:
- Writing new React components
- Implementing data fetching
- Reviewing code for performance issues
- Refactoring existing React code
- Optimizing bundle size or load times
Priority-Ordered Guidelines
Rules are prioritized by impact:
| Priority | Category | Impact |
|---|---|---|
| 1 | Eliminating Waterfalls | CRITICAL |
| 2 | Bundle Size Optimization | CRITICAL |
| 3 | Client-Side Data Fetching | MEDIUM-HIGH |
| 4 | Re-render Optimization | MEDIUM |
| 5 | Rendering Performance | MEDIUM |
| 6 | JavaScript Performance | LOW-MEDIUM |
| 7 | Component Structure | MEDIUM-HIGH (maintainability) |
| 8 | Testing | MEDIUM-HIGH (correctness) |
| 9 | Type Safety | HIGH |
Quick Reference
Critical Patterns (Apply First)
Eliminate Waterfalls:
- Use
Promise.all()for independent async operations (async-parallel)
Reduce Bundle Size:
- Avoid barrel file imports, import directly from source (
bundle-barrel-imports) - Defer non-critical third-party libraries (
bundle-defer-third-party)
Medium-Impact Patterns
Client-Side Data Fetching:
- Use Tanstack Query for automatic request deduplication (
client-request-dedupe) - Dependent query params are the value or
undefined, never| nullor a fake fallback; narrow at the caller so hooks stay strict, or guard withskipTokenwhen the hook must accept an optional param (client-request-dedupe)
Re-render Optimization:
- Use lazy state initialization for expensive values (
rerender-lazy-state-init) - Apply
startTransitionfor non-urgent updates (rerender-transitions) - Keep UI handlers plain; use Effect Events only for effect-fired logic (
rerender-useeffect-function-calls) - Never reset state with
useEffect; lift the discriminant and remount the branch (rerender-no-useeffect-state-reset) - Never add
useMemooruseCallback; leave memoization decisions to developers with profiler evidence (rerender-no-usememo-usecallback) - Never call
setStateduring render or insideuseEffect; derive during render or move state ownership to an intermediate component (rerender-no-setstate-in-render-or-effect)
Component Structure:
- One domain component/hook per file, one responsibility each — split bloated components (
structure-single-responsibility) - Keep component, hook, function, and utility APIs narrow: split oversized props, arguments, and return objects into focused units composed at the component level; wrapping the same values in one object is not a fix (
structure-narrow-apis) - Use PascalCase components for JSX-returning helpers; keep lowercase helpers for non-JSX values (
structure-component-naming) - Derive props/params instead of accepting a value computable from another arg (
structure-derive-dont-duplicate) - Extract complex derived logic into named locals plus predicates or pure helpers with early returns: oversized conditions, nested ternaries, ternaries that compute instead of picking (multi-line branches, or an
ascast re-asserting what the condition tested), fallback chains, andlet-based render prep are code smells, in render prep and in hook options, request builders, config maps, and reducers alike (structure-complex-derived-logic) - Pick the view with early
ifguards but keep the layout wrapper in one place — branch a body component, don't ternary or duplicate the shell (structure-early-return-render-branches) - For a fixed set of items, write one component per item with explicit props that owns its data and loading — don't map a config-object array onto a component shape (
structure-composition-over-config)
Testing:
- BDD tests that drive the real
@mastra/client-js+ React Query stack and mock only the network; nevervi.mockour own hooks/services/auth gating or the SDK (testing-bdd-no-mocks) - Avoid class-name assertions for visual behavior; prefer computed styles, user-visible behavior, or browser validation, and prefer no test over a className-only implementation mirror (
testing-no-classname-assertions)
Type Safety:
- No
astype assertions anywhere — production or tests; narrow with real type guards, query generics (querySelector<T>,getByRole<T>), typed fixture factories, orimplementson mocks.as constis the only allowed form. Do not replace a cast with a domain-type predicate that only checkstypeof value === 'object'; call that anisRecordhelper or validate the fields used (types-no-type-assertions) - Use
undefinedand optional?for absence, notnull; convert externalnullat boundaries, and keep leaf props strict so callers own absence and fallback rendering (types-no-null)
Rendering Patterns
- Animate SVG wrappers, not SVG elements directly (
rendering-animate-svg-wrapper) - Use
content-visibility: autofor long lists (rendering-content-visibility)
JavaScript Patterns
- Use Set/Map for repeated lookups (
js-set-map-lookups) - Use
toSorted()instead ofsort()for immutability (js-tosorted-immutable) - Early length check for array comparisons (
js-length-check-first)
References
Rule files are the canonical source for detailed guidance and examples:
references/react-best-practices-reference.md- Rule catalog with category order and rule-file pathsreferences/rules/- Canonical individual rule files organized by category
Load only the relevant rule file when implementing or reviewing a specific pattern. Use the catalog to choose the right rule without loading every example.
To look up a specific pattern, grep the rules directory:
grep -l "Promise.all" references/rules/
grep -l "barrel" references/rules/
grep -l "Tanstack" references/rules/
Rule Categories in references/rules/
async-*- Waterfall elimination (1 rule)bundle-*- Bundle size optimization (2 rules)client-*- Client-side data fetching (1 rule)rerender-*- Re-render optimization (6 rules)rendering-*- DOM rendering performance (2 rules)js-*- JavaScript micro-optimizations (3 rules)types-*- Type-safety / no-as-cast and no-nullrules (2 rules)structure-*- Component/hook/function/utility structure (7 rules)testing-*- BDD tests + mock-only-the-network policy + no className implementation-mirror assertions (2 rules)
Related skills
More from mastra-ai/mastra and the wider catalog.

smoke-test
Create and smoke-test a Mastra project in Chrome using Claude Code with Chrome MCP server

tailwind-best-practices
Tailwind CSS styling guidelines ensuring design system consistency in Mastra Playground UI.

e2e-tests-studio
Generate Playwright E2E tests validating product behavior for Mastra playground UI modifications.

ralph-plan
Interactive planning assistant for creating focused, well-structured ralph-loop commands

mastra
Comprehensive Mastra framework guide for agents, workflows, tools, and CLI operations.

mastra-factory
Operate and supervise Mastra Factory—manage projects, work items, queues, metrics, and autonomous operations.