Variants
A dialog has too many boolean modes
Replace combinations like compact, confirm, destructive, and showFooter with named compositions where behavior is visible at the call site.
01 / The skill · React · Component architecture
Vercel Composition Patterns: fewer switches, clearer components
This Skill helps redesign React components whose behavior is controlled by a growing list of boolean props. Its focus is composition, shared context, and explicit variants.
Publisher, source, and installation
Published by Vercel Labs · Type: React architecture Skill
Independent guide. Vercel Labs has not endorsed Floatboat.
Upstream installation
npx skills add vercel-labs/agent-skills --skill vercel-composition-patternsThis is the upstream Skill installation command, not a Floatboat installer.
A realistic request
The source favors compound components and provider-owned state over prop combinations that multiply. It is most useful while designing a component library or untangling a component whose API is hard to reason about.
Ask the agent
“Refactor this Modal with six boolean props into an API that supports confirm and edit flows without surprising combinations.”
A useful result
A useful proposal shows the new public API, one migrated call site, state ownership, and what happens to existing uses.
Where composition patterns help
Use this Skill when the component API has become difficult to use or extend.
State
Sibling controls need the same state
Place the state and actions in a provider rather than threading them through every intermediate component.
Library
Consumers need controlled flexibility
Expose compound parts or explicit variants so consumers can assemble layouts without reimplementing internals.
Cases that do not need this refactor
- A small component with one clear behavior and no API pressure.
- A performance audit; composition can clarify APIs without making rendering faster.
How to reshape a component API
Start from real call sites, identify stable parts, then move shared behavior behind an explicit interface.
- 01
Inspect actual callers
List the combinations that exist today and those that should not be possible.
- 02
Choose parts and state owner
Use compound components or explicit variants; keep the provider responsible for shared state.
- 03
Migrate representative uses
Convert common and edge call sites before removing the old API.
02 / Practical guide
Decide what callers should compose
A better API exposes meaningful parts. The pattern choice should follow how the component is used, not a blanket ban on booleans.
What is the boolean-prop problem?
Each new switch can interact with existing switches, creating undocumented combinations. The Skill recommends making meaningful variants explicit or letting callers assemble compound parts.
Does it require React 19?
Most composition guidance is general React architecture. The source marks React 19-specific API advice separately; skip that section for React 18 or earlier.
What you can take away
- A smaller, legible component API
- Explicit state ownership
- Representative migration examples
What to check first
- Do existing callers depend on undocumented combinations?
- Are the new parts understandable without reading implementation?
- Is React 19-only advice applicable?
Explore More Agent Skills
Read another Skill guide and check its original source before using it.
Frequently Asked Questions
What are compound components?
They expose related parts under a shared component API, often with context to coordinate state, so callers can assemble the structure they need.
Should every boolean prop be removed?
No. The concern is proliferating behavior modes and unclear combinations. A simple flag can remain if it keeps the API clear.
Will this Skill improve runtime performance?
Its main goal is maintainable component architecture. Measure separately if performance is the reason for the refactor.
Can React 18 projects use it?
Yes for the general patterns; the source explicitly separates React 19-only guidance, which should not be applied to older versions.
03 / Put it to work · Work through the refactor
Keep the component contract visible during refactoring
Bring the component, its call sites, and design constraints into one Floatboat task before changing the public API.