【免费下载链接】open-slideA slide framework built for agents.项目地址https://gitcode.com/gh_mirrors/op/open-slide点击查看免费下载导读本指南讲解 open-slide 仓库中vercel-composition-patterns技能包的核心架构规则——避免布尔属性泛滥Avoid Boolean Prop Proliferation。它面向两类读者一类是在 open-slide 的 UI 组件如packages/core/src/app/components/ui/下的组件或自己构建幻灯片组件时需要设计可扩展组件 API 的开发者另一类是编写代码的 Agent需要识别和重构「isThread、isEditing、isDMThread」这类布尔开关堆砌的组件。读完本文你将掌握布尔属性为何会产生指数级复杂度、如何用组合式Compound组件与显式变体重构它们以及 open-slide 源码中可验证的落地范例。规则定位为什么它是 CRITICAL 级架构规则该规则文件位于 .agents/skills/vercel-composition-patterns/rules/architecture-avoid-boolean-props.mdfrontmatter 中明确标注title: Avoid Boolean Prop Proliferationimpact: CRITICALimpactDescription: prevents unmaintainable component variants防止产生不可维护的组件变体tags: composition, props, architecture在整个技能包中这条规则与 architecture-compound-components.md 一起被归入Component Architecture组件架构分类并排在优先级第一位。正如 .agents/skills/vercel-composition-patterns/README.md 所述它的核心原则是组合优先于配置Composition over configuration——与其不断加属性不如让使用者自由组合提升状态Lift your state——状态放在 Provider 中而不是困在组件内部组合内部实现Compose your internals——子组件通过 Context 访问共享状态而不是接收一堆属性显式变体Explicit variants——创建ThreadComposer、EditComposer而不是一个带isThread的Composer。问题本质每个布尔属性都让状态空间翻倍规则文档给出了核心论断Dont add boolean props likeisThread,isEditing,isDMThreadto customize component behavior. Each boolean doubles possible states and creates unmaintainable conditional logic. Use composition instead.这里的数学是直观且可推导的一个组件每增加一个布尔属性其可能的状态组合数量就翻一倍。n个布尔属性意味着2^n种状态组合3 个布尔2³ 8种组合5 个布尔2⁵ 32种组合8 个布尔2⁸ 256种组合。而其中绝大多数组合是「不可能状态」例如isDMThread isThread同时为真时语义是什么isEditing isForwarding并存时渲染哪套操作测试用例、类型定义、代码审查者都必须逐一考虑这些组合。更隐蔽的问题是条件逻辑的嵌套顺序代码中isDMThread ? ... : isThread ? ... : ...的优先级本身就成了隐式契约一旦调用方传入的组合落在某个未预期的分支里渲染结果就变成「看似能跑但逻辑错误」。反模式示例一个 Composer六个布尔开关规则文档给出了一个教科书式的反面案例——一个聊天 Composer 组件用isThread、isDMThread、isEditing、isForwarding四个布尔属性连同channelId、dmId两个业务字段来控制所有变体function Composer({ onSubmit, isThread, channelId, isDMThread, dmId, isEditing, isForwarding, }: Props) { return ( form Header / Input / {isDMThread ? ( AlsoSendToDMField id{dmId} / ) : isThread ? ( AlsoSendToChannelField id{channelId} / ) : null} {isEditing ? ( EditActions / ) : isForwarding ? ( ForwardActions / ) : ( DefaultActions / )} Footer onSubmit{onSubmit} / /form ) }这段代码的问题清单不可维护的条件逻辑三段式三元表达式层层嵌套新增一个「转发到群组」的变体就要再插一层分支并重新梳理优先级组合爆炸4 个布尔开关意味着 16 种状态组合绝大多数没有意义隐式契约isEditing ? EditActions/ : isForwarding ? ...中的分支顺序就是没人写下来的规则改错顺序就会静默产生错误 UI无法被类型系统约束Props 层面允许任何布尔组合isEditing isForwarding这类非法状态在编译期无法拦截。从调用方的视角看这个组件同样难以理解——patterns-explicit-variants.md 用一句反问点破了这种体验「What does this component actually render?这个组件到底渲染了什么」Composer isThread isEditing{false} channelIdabc showAttachments showFormatting{false} /没人能一眼看出这个调用会渲染出什么 UI。正确做法组合式变体显式声明每个组件渲染什么规则文档给出的正确示例是把 Composer 拆成一个可复用的组合式骨架Composer.Frame、Composer.Header、Composer.Input、Composer.Footer然后用显式变体组件去组合出不同的能力// Channel composer function ChannelComposer() { return ( Composer.Frame Composer.Header / Composer.Input / Composer.Footer Composer.Attachments / Composer.Formatting / Composer.Emojis / Composer.Submit / /Composer.Footer /Composer.Frame ) } // Thread composer - adds also send to channel field function ThreadComposer({ channelId }: { channelId: string }) { return ( Composer.Frame Composer.Header / Composer.Input / AlsoSendToChannelField id{channelId} / Composer.Footer Composer.Formatting / Composer.Emojis / Composer.Submit / /Composer.Footer /Composer.Frame ) } // Edit composer - different footer actions function EditComposer() { return ( Composer.Frame Composer.Input / Composer.Footer Composer.Formatting / Composer.Emojis / Composer.CancelEdit / Composer.SaveEdit / /Composer.Footer /Composer.Frame ) }规则文档的收尾总结值得逐句品味Each variant is explicit about what it renders. We can share internals without sharing a single monolithic parent.也就是说每个变体都明确声明自己渲染什么共享的是内部零件而不是一个臃肿的父组件。调用方也因此获得了自文档化的 API——patterns-explicit-variants.md中对应的重构结果一目了然// Immediately clear what this renders ThreadComposer channelIdabc / // Or EditMessageComposer messageIdxyz / // Or ForwardMessageComposer messageId123 /类型系统现在也真正参与约束ThreadComposer只接受channelIdEditMessageComposer只接受messageId非法状态在编译期就不可能构造出来。正如该规则文件所述每个显式变体都清楚标明「使用哪个 Provider/状态、包含哪些 UI 元素、提供哪些操作」不存在需要推理的布尔组合也不存在不可能状态。支撑它的底层模式复合组件 Context 显式变体「避免布尔属性」并非孤立规则它依赖技能包内一整套相互咬合的模式见 .agents/skills/vercel-composition-patterns/SKILL.md 的规则分类复合组件Compound Components——architecture-compound-components.md 说明复杂组件应拆成「共享一个 Context 的复合组件」每个子组件通过 Context 而非 props 访问共享状态消费者按需拼装。其典型形态是Composer作为一个对象挂载Provider / Frame / Input / Submit / Header / Footer等子组件状态、操作actions与元信息meta由父级 Provider 依赖注入const ComposerContext createContextComposerContextValue | null(null) function ComposerProvider({ children, state, actions, meta }: ProviderProps) { return ( ComposerContext value{{ state, actions, meta }} {children} /ComposerContext ) } function ComposerInput() { const { state, actions: { update }, meta: { inputRef }, } use(ComposerContext) return ( TextInput ref{inputRef} value{state.input} onChangeText{(text) update((s) ({ ...s, input: text }))} / ) } // Export as compound component const Composer { Provider: ComposerProvider, Frame: ComposerFrame, Input: ComposerInput, Submit: ComposerSubmit, Header: ComposerHeader, Footer: ComposerFooter, Attachments: ComposerAttachments, Formatting: ComposerFormatting, Emojis: ComposerEmojis, }注意示例中读取 Context 使用的是 React 19 的use()而非useContext()——这正是技能包中 react19-no-forwardref.md 所强调的 React 19 API 迁移该技能包同时提示React 19 之前请跳过此节。状态提升与 Context 接口——同属该技能包的 state-lift-state.md把状态提升进 Provider 以便兄弟组件共享与 state-context-interface.md定义state / actions / meta三段式 Context 接口为复合组件提供了状态侧的支撑正是前面ComposerContextValue三元组的来源。显式变体——patterns-explicit-variants.md 把「拆变体」进一步落地为带各自 Provider 的独立组件每个变体内部可以用不同 Provider 注入不同业务状态如ThreadProvider、EditMessageProvider、ForwardMessageProvider进一步消除了「一个组件多个模式」的残留。仓库中的落地证据open-slide 组件库正是这么做的该规则并非悬空的教条——open-slide 自己的组件实现就是「Context 复合组件」的实际案例可以直接对照源码验证。ToggleGroup共享 Context 的复合组件。在 packages/core/src/app/components/ui/toggle-group.tsx 中ToggleGroup建立了一个包含size / variant / spacing的ToggleGroupContext用ToggleGroupContext.Provider把配置注入子树ToggleGroupItem则通过React.useContext(ToggleGroupContext)读取这些值来推导自己的样式context.variant || variant、context.size || size。这正是「父组件通过 Context 而非逐项传 prop 分发共享配置」的组合式结构spacing这类样式配置只需在根上声明一次所有子项自动继承。Provider 化的状态管理。open-slide 源码中存在多处「状态提升到 Provider」的实现可以印证该技能的 state 侧规则inspector-provider.tsxInspector 的编辑状态由 Provider 统一管理子组件通过 Context 访问design-provider.tsx样式面板的设计状态对应use-design.ts的消费通过 Provider 注入page-context.tsx 与 step-context.tsx页与 Step 的上下文以 Provider 形态向幻灯片渲染树广播history-provider.tsx编辑历史状态集中管理。从这些文件可以看出open-slide 的 UI 层广泛采用「Provider Context 消费」而非「把布尔开关塞进每个子组件」的架构——这正是 architecture-avoid-boolean-props.md 所倡导的方向在仓库中是可持续验证的实现事实。另外该技能包的用途在 SKILL.md 中有明确描述它专门用于「重构存在布尔属性泛滥的组件、构建可复用组件库、设计灵活组件 API、审查组件架构」等场景。它甚至点明了这套模式对 Agent 的价值——组合式的代码库「让人类和 AI Agent 都更容易在规模增长时继续工作」。实战检查清单如何把这条规则落到 open-slide 的组件上结合规则文档与技能包 README.md可以在写或审查组件时执行以下检查数一数 props 里的布尔开关出现isXxx、showXxx、hasXxx超过一个时立即评估是否进入2^n状态空间识别「模式」而非「选项」isThread、isEditing这类描述的是组件的不同工作模式应该拆成ThreadComposer、EditComposer这样的独立变体组件参考 patterns-explicit-variants.md共享部分下沉为复合组件把Frame / Header / Input / Footer这类骨架作为复合组件暴露参考 architecture-compound-components.md变体之间共享零件但各自声明渲染内容用 Context 承载共享状态变体内共享的状态放进 Provider子组件用use(Context)消费避免 prop drilling 卷土重来参考 state-lift-state.md 与 state-context-interface.md验证调用方能否「一眼看懂」如果一行调用X isA isB{false} ... /无法瞬间说清渲染结果说明重构还没到位。总结「避免布尔属性泛滥」这条 CRITICAL 级规则的实质是把组件的变体从调用方的 props 迁移到独立的组件类型布尔开关把复杂度分摊给所有调用点而组合式变体把复杂度收拢到一处、显式声明其余调用点拿到的是自文档化、类型受限、不可能构造非法状态的 API。open-slide 的技能包为其配套了复合组件、状态提升、Context 接口与显式变体一整套模式仓库自身的 UI 组件如toggle-group.tsx及各类 Provider也验证了这些模式在真实项目中的可落地性。对编写 open-slide 相关组件的开发者与 Agent 而言这条规则是组件架构审查的第一道关卡——它能最直接地防止组件在迭代中滑向「不可维护的变体集合」。赞分享【免费下载链接】open-slideA slide framework built for agents.项目地址https://gitcode.com/gh_mirrors/op/open-slide点击查看免费下载相关推荐OpenMetadata UI 组件架构指南以组合取代布尔 Prop根治组件状态爆炸OpenMetadata UI 组件架构指南以组合取代布尔 Prop根治组件状态爆炸 导读 本文讲解 OpenMetadata 前端工程 openmeta数据目录数据血缘数据治理后端MCP 服务如何用 Bun 开发 opencode-anthropic-auth工程化工具链完整指南如何用 Bun 开发 opencode anthropic auth工程化工具链完整指南 项目简介这个 Bun 小项目做了什么 opencode anthSupabase 仓库中的 React 组合式架构实践用显式组件变体消除布尔 Prop 的模式爆炸Supabase 仓库中的 React 组合式架构实践用显式组件变体消除布尔 Prop 的模式爆炸 本篇基于 Supabase monorepo 中 .c后端前端数据库上一篇完整下载番茄小说到本地5 种格式、3 步上手的离线备份方案下一篇WechatRealFriends快速检测单向好友创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考