文档技术博客教程【免费下载链接】weekly前端精读周刊。帮你理解最前沿、实用的技术。项目地址https://gitcode.com/GitHub_Trending/we/weekly点击查看免费下载容器组件是可视化搭建系统的地基——画布本身就是一个容器Tab、卡片、富文本内嵌无一不是容器能力的体现。本文基于《可视化搭建》系列中「容器组件设计」的核心思路围绕三类容器形态深入讲解children约定、treeLike 结构与propTypes声明式插槽三种容器定义方式并分析其背后的组件树遍历与序列化问题帮助你理解为何可视化搭建中不存在容器组件这个概念。容器组件的三类形态可视化搭建会遇到如下三类容器组件简单容器以children容纳子组件的容器是最常见、最基础的形态。卡片容器以props.header、props.footer等多个插槽容纳子组件的容器插槽数量固定。Tab 容器以props.tabPanel[x]等动态数量插槽容纳子组件的容器插槽数量随配置变化。值得注意的一点是画布本身也是一个容器组件因此可视化搭建系统从根上就离不开容器。从系列前文可以知道画布的本质等价于ComponentLoader treePath /即从根节点渲染一个组件实例见 可视化搭建/278.ComponentLoader 与动态组件.md根节点组件往往就是最顶层的容器向下容纳整棵组件树。容器的定义不需要特殊声明设计上最核心的约定是任何组件都可能是容器组件只要它将props.children、props.footer等任何属性作为 ReactNode 渲染即可。因此框架不需要为组件声明我是否容器这一特殊type只需要将某些组件 Key 声明为 ReactNode 节点。这样设计的好处是组件代码完全不感知框架逻辑只需按普通 React 组件的写法渲染 props容器能力是渲染某个属性这一朴素行为的自然体现而非额外的框架概念任何第三方组件库如 Antd无需适配只要其某个 props 接受 ReactNode就能无缝接入平台参见 可视化搭建/269.组件注册与画布渲染.md 中组件树应该能描述出任何组件想要的 props 属性的原则。Children 约定最直观的容器children因为太常用而单独强调出来。可以在组件实例定义中直接写children属性它是一个数组import { ComponentInstance } from designer; const componentTree: ComponentInstance { componentName: div, children: [ { componentName: input, }, ], };对于这个组件Designer 会将children定义的属性理解为组件实例并真正解析为 React 实例传递给props.children因此组件渲染代码可以直接使用children渲染import { ComponentMeta } from designer; const divMeta: ComponentMeta { componentName: div, element: ({ children }) div{children}/div, };这种约定的优势是直观自然组件代码不用关心框架逻辑element函数拿到什么就渲染什么自然而然实现了容器功能。关于children还有两个细节需要了解出自 可视化搭建/269.组件注册与画布渲染.md组件树结构ComponentInstance与组件实例结构是同构的children是描述树结构的三大要素之一另外两个是componentName与propschildren理论上可以合并到props.children但建议两种位置同时支持children作为顶层约定props.children作为 treeLike 属性两者同时定义时前者优先级更高。treeLike 结构任意 props 位置都是插槽仅支持children远远不够容器组件往往需要多个插槽。Designer 的约定是只要将任意组件 props 定义为数组模式并且包含componentName就认为该属性应解析为 ReactNode。这就是 treeLikeComponentTreeLike结构。下面的例子中div组件初始化就会渲染一个input组件在props.header位置import { ComponentMeta } from designer; const divMeta: ComponentMeta { componentName: div, element: ({ header }) div{header}/div, defaultProps: { header: [ { componentName: input, }, ], }, };也可以在描述组件树时直接写在对应 props 位置import { ComponentInstance } from designer; const componentTree: ComponentInstance { componentName: div, props: { header: [ { componentName: input, }, ], }, };从element视角看props.header从普通字符串变成React 实例组件代码无需任何改动即可在对应位置渲染出子组件详细对比见 可视化搭建/269.组件注册与画布渲染.md 中Props 上的 ComponentTreeLike 属性一节。不过这种约定存在两个天然缺陷由于 treeLike 会自动转成实例组件无法拿到 treeLike 的原始值由于 treeLike 位置不确定为避免深层解析的性能损耗只解析props第一级节点会导致嵌套层级较深的 treeLike 无法被解析到。要解决这两个缺陷就需要第三种方式propTypes。PropTypes用户 100% 掌控的声明式插槽在组件元信息propTypes属性中定义更细致的容器插槽位置。propTypes采用简化版结构而非 JSONSchema因为框架没必要内置 props 类型校验能力可以交给业务层处理const tabMeta { componentName: tab, propTypes: { tabs: [ { panel: element, }, ], }, };当组件实例如下定义时const componentInstance { componentName: tab, props: { tabs: [ { title: tab1, panel: { componentName: card, }, }, { title: tab2, panel: { componentName: text, }, }, ], }, };组件拿到的props.tabs[0].panel就是一个可以直接渲染的 React 组件实例因为在propTypes中定义了tabs[].panel路径是一个组件实例。关于propTypes的语法约定出自 可视化搭建/269.组件注册与画布渲染.mdheader: element表示header是单个 React Elementcontent: [element]表示content是 React Element 数组tabs: [{ panel: element }]表示tabs是对象数组其中panel是 React Element{}表示 value 是对象[]表示 value 是数组为数组时仅支持单个子元素因为单项即是对数组每一项类型的定义配合组件树描述可以精确将对应element类型转化为组件实例而对于基本类型primitive如names: [a, b, c]保持原样传给组件。通过配置更深层嵌套结构treeLike 的两大缺陷无法拿原始值、深层无法解析都被解决了。与 runtimeProps 的配合需要补充的是propTypes只解决哪些 props 位置是 ReactNode的问题而运行时函数如onClick则由runtimeProps注入见 可视化搭建/269.组件注册与画布渲染.md。两者组合起来可以让element函数对接任何成熟组件库而不需要组件库做任何适配工作。propTypes 引发的组件树遍历问题propTypes设计带来一个需要正视的问题组件实例位置定义在组件元信息上因此仅靠组件树无法做遍历——遍历父节点时不结合componentMeta就无法确认哪些 props 位置是子组件实例。这会带来两个问题遍历变慢极端情况下如果大量组件是远程注册的三方组件会导致需要一层层串行远程拉取组件实例遍历过程明显变慢。版本升级错位更极端的场景是当组件版本升级导致propTypes变化一些原本不是组件实例的位置成为了组件实例或者反之此时拉取最新组件元信息读取的propTypes可能就是错的。因此实现方案应该是将组件元信息定义的propTypes拷贝一份到组件实例这样可以仅凭组件树自身来遍历组件树无需串行拉取远程元信息定义在组件树上的propTypes一定对应当前组件树的结构杜绝版本错位问题。这一点与框架内置 API 的设计理念一脉相承内置的getComponent、deleteComponent、setProps等操作都以组件 ID 为参数在内部通过维护 ID 与树路径的映射表实现 O(1) 复杂度的组件树操作见 可视化搭建/271.可视化搭建内置 API.md。实战印证Tabs 与富文本容器children与 treeLike 这两个约定足以实现业务基本够用的容器定义能力。系列实战章节给出了两个典型案例见 可视化搭建/280.场景实战.mdTabs 组件利用props.tabs存放 tabs 配置props.content存放每项 TabPanel 的子组件因为顺序永远与props.tabs保持一致可以直接用下标匹配const tabs { componentName: tabs, element: TabsComponent, defaultProps: { // 存放 tabPanel 配置 tabs: [ { title: tab1, key: 1, }, ], // 存放每个 tabPanel 内子画布的组件实例 content: [ { componentName: gridLayout, }, ], }, };Tabs 组件实现完全与平台解耦只消费props.tabs与props.content即可。富文本内嵌组件实例与 Tabs 思路一致区别是富文本内嵌入的组件实例数量不固定每个组件实例对应富文本某个 block id。实现上只需将 block id 与组件实例 id 绑定组件实例存储在props.blockElements中渲染时按componentId匹配即可。此外画布渲染 APIComponentLoader支持按组件 ID、按组件树路径以及standalone动态组件三种加载方式见 可视化搭建/278.ComponentLoader 与动态组件.md其中按组件树路径加载如treePathchildren.0正体现了容器插槽位置在组件树上的可寻址性而动态组件更是一个 props 属性是组件实例这一容器理念的极致延伸——甚至组件可以不存在于组件树中。总结我们通过children与 props 上 treeLike 这两个约定实现了业务基本够用的容器定义能力仅凭这两个约定就可以实现几乎所有容器需要的效果。propTypes定义补全了约定拓展性的不足让 props 任何位置都可能成为组件实例只需要付出额外定义propTypes的代价。阅读到这相信你已经理解可视化搭建其实不存在容器组件的概念。一个组件之所以是容器仅仅因为它的某个 prop 属性是组件实例而它恰好将该属性渲染到某个位置甚至用createPortal挂载到其他 DOM 节点。因此对容器组件我们不需要设计一种新的type而是允许任意位置属性定义为实例。在《可视化搭建》系列的后续章节中还会基于这一基础继续引入组件值与联动见 可视化搭建/273.组件值与联动.md、组件值校验见 可视化搭建/275.组件值校验.md等能力而容器组件的这套定义方式始终是整套体系的基石——它让描述组件树与渲染组件彻底解耦也让业务在不需要理解框架内部实现的前提下自由组合出任意复杂的容器形态。赞分享文档技术博客教程【免费下载链接】weekly前端精读周刊。帮你理解最前沿、实用的技术。项目地址https://gitcode.com/GitHub_Trending/we/weekly点击查看免费下载相关推荐可视化搭建组件值校验实战从 valueValidator 声明到自定义异步规则可视化搭建组件值校验实战从 valueValidator 声明到自定义异步规则 组件值校验是可视化搭建框架为组件实例提供的值守卫能力当组件值发生变化时文档技术博客教程可视化搭建之组件值与值联动声明式多对多联动协议的设计与实战可视化搭建之组件值与值联动声明式多对多联动协议的设计与实战 本篇技术指南聚焦可视化搭建框架设计中「组件值」与「值联动」两个核心概念先抽象出每个组件实例唯一的文档技术博客教程FIFA 23实时编辑器完整指南免费打造你的梦幻球队FIFA 23实时编辑器完整指南免费打造你的梦幻球队 FIFA 23实时编辑器是一款功能强大的游戏修改工具让玩家能够深度定制球员能力、球队管理和游戏体验。通游戏开发上一篇XXMI启动器实操指南一个免费界面管住6款游戏的模组环境下一篇思源宋体CN落地教程7个字重、一套TTF免费商用的中文排版方案创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考