About react-boundaries
A React development skill for deciding where state, data fetching, and side effects belong in a component tree. It helps developers reduce prop drilling and oversized parent data hubs while retaining explicit exceptions for coordination, routing, and prefetching.
Key features
- 01Place state and queries at the lowest suitable boundary
- 02Use IDs with leaf subscriptions instead of payload drilling
- 03Compose layouts with children and slots
- 04Apply explicit rules for hoisting data
- 05Review ownership and verify affected code
Use cases
- 01Refactor state ownership in a React feature
- 02Replace prop pipelines with component composition
- 03Decide whether route-level data loading is justified
Install
Copy the command and run it in a terminal.
npx skills add https:/ / github.com/ dobroslavradosavljevic/ skills --skill react-boundariesAfter installing, type/react-boundariesin Claude Code to confirm it loaded.
Bundled files
References and scripts installed along with SKILL.md.
agents/openai.yamlreferences/anti-patterns.mdcomposition.mdownership.mdtanstack-patterns.mdDetails
From the project READMEReact Boundaries
Own state, data, and side effects at the lowest correct boundary. Parents compose structure; they do not become data hubs.
Principle: a component should own what it needs to render and act—unless another boundary must genuinely coordinate, gate, or load in parallel.
Hard Defaults
- Push down. State and fetches live with the consumer. Lift only via the exception list.
- Pass identity, not payloads. Give children an
id(or stable handle); let them subscribe or query. Do not drill entities through wrappers that never use them. - Compose UI, don’t pipe props. Prefer
children/ slots / named parts over threadingdata,isLoading, and handlers through layout shells. - Shared clients, local hooks. One API or QueryClient; many leaf hooks. Do not centralize “call the API” five layers up.
- Structure over memo theater. Fix ownership and tree shape before spraying
memo/useCallback/useMemo. Prefer patterns that work with React Compiler. - Justify every hoist in one line when you lift or route-fetch (“SEO”, “gate before mount”, “sibling sync”, “anti-waterfall”).
When Hoisting Is Correct
Hoist state or data ownership only for:
| Exception | Own at |
|---|---|
| Route / SSR / SEO needs data before paint or for meta | Router loader, Start server function, or RSC prefetch |
| Auth, permissions, or “don’t mount until X” | Route or parent gate |
| Two+ siblings must share one interactive source of truth | Nearest common parent or a narrow store |
| Parent must know which children exist before they can fetch | Parent / loader (anti-waterfall) |
| Cache already dedupes the same key | Leaves still subscribe; parent may prefetch only |
Everything else stays down. Details: ownership.md.
Workflow
- Scope — feature, route, or component tree the user named.
- Map ownership — for each piece of state and each query/mutation, name the owner and who re-renders when it changes.
- Apply defaults — move ownership down; replace drilled payloads with ids + leaf subscriptions; replace prop pipelines with composition.
- Apply TanStack patterns — tanstack-patterns.md.
- Check composition — composition.md.
- Kill anti-patterns — anti-patterns.md.
- Verify — typecheck/lint/tests for the touched surface; confirm high-churn state no longer sits in page/route shells.
Placement Checklist
Before finishing a change, answer:
- Who re-renders if this state or query updates?
- Who actually uses this data or state?
- Can the leaf own the query/mutation (or subscribe to a shared key)?
- Are intermediates composing UI or only forwarding props?
- If hoisted: which exception applies (one-line justification)?
- Is Context / Store carrying stable deps or high-churn values that should be local?
Non-Goals
- Not “never use Context,” “never use route loaders,” or “never pass props.”
- Not restyling, a11y primitive design, or general React API docs.
- Not replacing TanStack Query with ad-hoc parent
useEffectfetching.
Completion
Report briefly:
- Ownership moves (what moved down or stayed up, and why).
- Prop-drilling or data-hub removals.
- Prefetch vs subscribe split (if any).
- Remaining hoists with their exception justification.