React 组合模式
将以下提示词粘贴到你的 AI 对话框中:
请根据 https://skillhub.cn/install/skillhub.md,安装 @kunlungrowth/kg-composition-patterns 技能。
技能介绍
布尔 prop 爆炸与组件僵化
在构建可复用 UI 库(如 Composer 或 Modal)时,开发者常依赖 isEditing、isThread 或 isDM 等布尔属性来切换组件行为。随着业务迭代,每增加一个布尔值,内部状态组合便呈 2^n 增长,导致组件内充斥着冗长的条件分支。这种“布尔 prop 堆叠”不仅让组件变得僵化,也大幅推高了维护成本与认知负荷。
复合组件与状态注入的重构路径
本技能通过结构化的工程化步骤,将臃肿的大类组件拆解为灵活的复合组件。首先,扫描并定位高优先级的布尔 prop 信号;随后,依据对照表选择重构手法,例如使用 architecture-avoid-boolean-props 剥离布尔逻辑,或通过 state-context-interface 定义通用的 { state, actions, meta } 上下文接口。
在实操阶段,技能会指导你搭建 Frame、Header、Input 等子组件骨架,并将状态管理下沉至 Provider 层。这样不仅实现了“同 UI、不同状态实现”的解耦,还能输出一份包含问题清单、复合组件规划及重构步骤的 ComponentRefactorPlan 工件,同时附带关键的 before/after 代码对比。
适用边界与技术取舍
该模式专为多形态、高复用性的复杂容器组件设计。对于仅包含单一变体的纯展示型叶子组件(如基础的 Button),引入复合结构反而徒增复杂度,应当跳过。此外,若项目基于 React 18 及以下版本,需注意规避 React 19 专属规则,继续使用 useContext 与 forwardRef 进行上下文传递。服务端数据获取逻辑也不在此技能的覆盖范围内,需交由专门的 React 最佳实践技能处理。
使用场景
- 在开发可复用的 Composer 组件时,遇到 isEditing 和 isThread 等布尔属性导致逻辑混乱,需要重构为复合组件结构。
- 搭建供多业务线接入的 UI 组件库,需通过 Provider 接口注入本地态与全局同步态,保证组件形态统一。
- 评审历史遗留的复杂表单组件,需要将耦合在 UI 中的业务状态剥离并下沉至上下文进行管理。
适合人员
- 前端工程师,正在维护包含大量条件分支的祖传组件,希望降低后续维护成本。
- 组件库作者,需要设计灵活且可扩展的架构,以支持不同业务场景下的定制化需求。
- 技术负责人,负责评审前端架构,寻求解决组件状态耦合和复用性差的最佳实践。