react-composition

该技能提供了一套系统化的 React 组件组合模式，主要解决组件设计中布尔属性泛滥导致的复杂度爆炸问题。核心包含六大模式：避免布尔属性 proliferation（通过显式变体替代条件渲染）、复合组件（通过 Context 在子组件间共享状态）、泛型上下文接口（实现依赖注入，使同一 UI 可对接不同数据源）、状态提升（将状态移至 Provider 消除 prop drilling）、显式变体组件（用明确命名替代布尔组合）、以及优先使用 children 而非 render props。

显著优点在于通过组合替代条件判断，将组件状态复杂度从指数级（2^n）降至线性，使代码更可预测。复合组件模式让 API 自文档化，开发者可像搭积木般组装界面。依赖注入接口实现了 UI 与业务逻辑的解耦，同一套组件可无缝切换本地状态、全局状态或服务端状态。状态提升彻底解决了 sibling 组件通信难题，无需 ref forwarding 或事件总线。

潜在缺点包括对初学者较陡峭的学习曲线，需要掌握 Context、闭包、渲染优化等进阶概念。短期内会增加代码量和文件数量，存在过度设计风险——简单组件强行应用可能导致"为了模式而模式"。Context 使用不当可能引发性能问题（未优化的重渲染）。此外，示例使用了 React 19 的 use() Hook，旧版本需改用 useContext。

适合中高级 React 开发者、设计系统维护者及前端架构师。特别适用于构建组件库、重构遗留"神组件"（God Component）、或设计需要多态行为的专业级 UI 系统。对追求长期可维护性的中大型团队价值最高。

使用风险主要来自性能与兼容性两方面：Context 更新机制可能导致不必要的大规模重渲染，需配合 React.memo 和 useMemo 使用；React 版本兼容性需注意；作为纯指南性质技能，实施效果高度依赖开发者理解，错误应用可能比传统方式更糟。建议在代码审查中配套使用。

核心用法

该 skill 提供 6 种 React 组合设计模式，帮助开发者构建灵活、可维护的组件架构：

| 模式 | 核心思想 | 适用场景 |

|------|---------|---------|

| 避免布尔属性泛滥 | 用显式组合替代多布尔 props 条件渲染 | 3+ 布尔属性的复杂组件 |

| 复合组件 | Context 共享状态，命名空间导出子组件 | 需要灵活组合的 UI 套件 |

| 泛型 Context 接口 | 定义 state/actions/meta 契约，实现 UI 与数据层解耦 | 同一 UI 适配不同数据源 |

| 状态提升 | 将状态移至 Provider，支持兄弟组件访问 | 非视觉嵌套的组件需共享状态 |

| 显式变体组件 | 为每种场景创建独立组件，而非配置项 | 互斥场景，避免不可能状态 |

| Children 优于 Render Props | 用 children 组合替代 renderX 回调 | 除非父组件需回传数据 |

显著优点

• 根治布尔属性灾难：条件分支从指数级增长降为线性组合，消除"不可能状态"
• API 自文档化：<ThreadComposer /> 比 <Composer isThread isNotDM showAttachments /> 意图清晰
• 可测试性提升：Provider 层可 mock，UI 层纯渲染逻辑
• 团队协同友好：新成员通过组件名即可理解用途，无需阅读复杂 props 文档

潜在局限

• 学习曲线：团队需适应 Context 心智模型，Junior 开发者可能过度使用
• 样板代码增加：简单场景下 Provider + Context 比直接 props 传递冗长
• 性能考量：频繁更新的 Context 需配合 useMemo/useCallback 优化
• 工具链依赖：TypeScript 对泛型 Context 的支持能显著提升体验，纯 JS 项目类型安全较弱

适合人群

• 维护大型 React 应用的中高级前端工程师
• 构建内部组件库/设计系统的技术负责人
• 面临"props 爆炸"重构需求的遗留项目团队
• 追求 Clean Architecture 与 SOLID 原则的开发者

常规风险

• 过度工程化：简单组件（2 个以下变体）无需全套模式
• Context 嵌套地狱：多层 Provider 需明确文档说明数据流
• React 版本兼容性：文档示例使用 React 19 use() Hook，旧版本需适配为 useContext