变体
弹窗有太多布尔模式
把 compact、confirm、destructive、showFooter 等属性组合改成有名称的组件组合，让调用方看得出行为。
01 / Skill 档案 · React · 组件架构
Vercel Composition Patterns：少一点开关，多一点清晰组合
当 React 组件越来越依赖布尔属性控制行为时，这个 Skill 引导你改用组合、共享上下文与明确的变体。
发布方、原始来源与安装方式
原发布方 Vercel Labs · 类型: React 架构 Skill
本页为独立介绍；Vercel Labs 未对 Floatboat 作出背书。
上游安装方式
npx skills add vercel-labs/agent-skills --skill vercel-composition-patterns这是上游 Skill 的安装命令，不是 Floatboat 安装器。
一个具体请求
原始规则主张用复合组件和 Provider 管理状态，而非让属性组合无限增加。它适合设计组件库，或梳理 API 已经难以理解的组件。
向 Agent 提问
“把这个带六个布尔属性的 Modal 重构成能支持确认和编辑流程、又不会出现意外组合的 API。”
应该得到什么
合格方案应展示新公共 API、一个迁移后的调用示例、状态归属，以及旧用法如何处理。
哪些组件值得重新设计
当组件 API 难用、难扩展时再用它，而不是为每个简单组件增加抽象。
状态
兄弟控件需要共享状态
把状态与操作集中到 Provider，而不是逐层传给所有中间组件。
组件库
组件库使用者需要可控的灵活性
提供复合部件或明确变体，让使用者能组合布局，同时不必重新实现内部逻辑。
不必为此重构的情况
- 行为单一、接口清楚且没有扩展压力的小组件。
- 性能审查；组合模式能让 API 更清晰，但不保证渲染更快。
如何重新组织组件 API
从真实调用位置出发，找出稳定部件，再把共享行为放进明确的接口。
- 01
检查真实调用方
列出现有属性组合，以及本不应该存在的组合。
- 02
确定部件与状态归属
使用复合组件或明确变体，让 Provider 负责共享状态。
- 03
迁移代表性用法
先迁移常见和边缘调用，再移除旧接口。
02 / 使用指南
先确定调用方需要组合什么
更好的 API 应暴露有意义的部件。模式选择要看组件如何被使用，而不是机械禁止所有布尔属性。
布尔属性过多会带来什么问题？
每增加一个开关，都可能与已有开关产生新的组合。这个 Skill 建议把有意义的变体写明，或让调用方组合复合部件。
必须使用 React 19 吗？
大部分组合建议属于通用 React 架构。原文单独标记了 React 19 API 建议；React 18 及更早版本应跳过那部分。
你能拿到什么
- 更小、更清晰的组件 API
- 明确的状态归属
- 有代表性的迁移示例
使用前先核对
- 现有调用是否依赖未文档化的属性组合？
- 不读实现代码也能看懂新部件吗？
- React 19 专属建议适用于当前项目吗？
探索更多 Agent Skills
查看其他 Skill 指南，并在使用前核对原始来源。
常见问题
什么是复合组件？
它把相关部件放在同一套组件 API 下，通常通过上下文协调状态，让调用方按需要组合结构。
所有布尔属性都要删除吗？
不用。问题在于行为模式膨胀和组合含义不清；如果一个简单开关依然清楚，就无需强行移除。
这个 Skill 会提升运行性能吗？
它主要解决组件架构的可维护性。如果重构目的是性能提升，仍需单独测量。
React 18 项目可以用吗？
通用模式可以使用；原文单独标记了 React 19 专属建议，旧版本不应套用。