| name | review-react-component-design |
| description | Review React component designs. Use for boundaries, APIs, opt-outs, and bundles. |
React component design review
Read the proposal, nearby records, and relevant React code, tests, exports, and package metadata.
- Ask whether the proposal is a reusable primitive or app/skin composition before adding a component or part.
- Trace ownership and data flow across core, DOM behavior, and React. Check effects and cleanup.
- Review compound anatomy, React and CSS APIs, and whether each addition has a consumer. Leave visual structure to CSS. If the surface spans independent features, separate them into another component or hook. Treat descendant selectors,
:has(), and other complex selectors introduced by composition as a likely sign of a weak primitive boundary or missing data-* or CSS custom-property hooks.
- Exercise omission, render replacement, styling, behavior, and import opt-outs.
- Weigh API complexity against bundle cost and verify client boundaries. Compound APIs should use tree-shakeable ESM namespace re-exports rather than runtime namespace objects. Check accessibility, interaction, and SSR constraints.
Use packages/react/src/ui/, use-render.tsx, and package metadata as evidence. Report findings by severity with the smallest change.
Where local precedent is insufficient, consult React for data flow, Base UI for headless composition, WAI-ARIA APG for interaction patterns, and webpack for tree shaking.
Example
Input: “Review this React chapter-menu design.”
Output: Prioritized findings about boundaries, APIs, opt-outs, SSR, accessibility, and bundle cost.
