前端精读周刊：可视化搭建的第一步——如何抽象出统一的逻辑层

文档技术博客教程【免费下载链接】weekly前端精读周刊。帮你理解最前沿、实用的技术。项目地址https://gitcode.com/GitHub_Trending/we/weekly点击查看免费下载导读本文是前端精读周刊可视化搭建系列的开篇之作聚焦做任何可视化搭建项目前必须先思考的抽象问题。文章以表单搭建、中后台搭建、BI 仪表盘、大屏搭建四类场景为样本论证它们背后存在一个 UI 无关的逻辑层最大公约数并逐条拆解逻辑层必须解决的组件树结构、增删改查、生命周期、渲染与拓展五大问题。读完本文你将掌握一套以逻辑层打底、上层注册组件与布局的分层抽象方法论为后续亲手实现一个 React 可视化搭建器组件树 组件元信息 数据流铁三角打下理论基础。为什么做可视化搭建第一步必须先思考抽象在做任何可视化搭建项目时第一步都要思考如何抽象。这不是一句口号而是有明确后果的API 杂乱、难以维护如果不抽象搭建项目做到后期API 会越堆越多且彼此纠缠代码熵增导致维护成本飙升。自我怀疑做到一半甚至会怀疑为什么需要一个搭建框架怀疑把框架去掉会不会效率更高。无法水平拓展后期会发现系统不能自然地水平拓展到仪表盘、大屏、表单搭建等新场景每次新场景都要重新造轮子。所以无论维护的可视化搭建系统上层是 BI、大屏、表单填报还是脑图都要先思考这些系统背后的底层是什么需不需要抽象抽象的意义和价值在哪里以本仓库系列后续篇章为例抽象的价值在 可视化搭建/269.组件注册与画布渲染.md 中体现为极简的DesignerAPIcomponentMetascomponentTree两个入参即可渲染画布在 可视化搭建/270.画布与组件元信息数据流.md 中体现为数据流、组件元信息、组件实例三者的铁三角这正是前期抽象沉淀下来的成果。什么是可视化搭建边界与归类表单搭建、中后台应用搭建、BI 仪表盘搭建、大屏搭建都算可视化搭建因为它们都是在一个画布上拖拖拽拽完成的。那么边缘场景如何归类组件配置表单如果基于 UI 组件树抽象它就是可视化搭建如果基于表单结构抽象它就是 JsonSchema。聚焦单组件分析的可视化探索、幻灯片同样存在归类问题。关键判断在于所有业务场景都是数据完全映射 UI吗不一定。UI 可以为了用户操作方便加入更多辅助元素甚至把一个属性拆成多个 UI 填写。所以基于 UI 组件树抽象的可视化搭建一定可以覆盖所有表单场景但不一定是描述效率最高的方式。如果不做统一抽象后果是每种可视化搭建场景各定义一套协议与实现按平台复杂度算同时维护两套类搭建平台的成本是两倍不同维护人员之间很难交流有些本可按搭建思路解决的场景因实现时经验不足没有抽象甚至另做了一套定制抽象回过头来积重难返团队不得不接受多套笨重实现并存的现状。因此建议将这些场景都视为可视化搭建场景用一套接口描述结构、API 方法让看似百花齐放的编辑器之下拥有统一的上下文与实现。可视化搭建的分层寻找四类平台的最大公约数对于不同种类的可视化搭建平台可以尝试寻找其分层设计的最大公约数。把可视化搭建底层设定为逻辑层——即这一层是 UI 无关的仅关心组件树结构、逻辑功能——那么四类典型平台的分层结构如下平台类型分层结构表单搭建逻辑层、表单联动协议层、表单控件、业务层中后台应用搭建逻辑层、应用联动协议层、应用控件、业务层BI 仪表盘逻辑层、筛选联动协议层、可视化控件、业务层大屏搭建逻辑层、画布编辑控制器层、可视化控件和基础图形控件、业务层可以看到逻辑层位于所有类型搭建系统的最底层是开发人员统一上下文的关键。逻辑层应包含以下基础能力定义组件树结构。定义组件元信息。按照组件树结构递归渲染画布。支持布局、取数、联动、筛选、校验等一系列拓展能力业务可根据需要定制。提供所有业务层都需要的能力比如性能优化的组件冻结、状态管理、对组件树增删改查的 API。逻辑层完备后开发上层应用会轻松很多只要注册组件、根据业务需要在组件树初始化、组件初始化或组件元信息注册时添加定制逻辑、与系统功能对接并补充业务特色的自定义布局能力就可以用简单的三言两语说清楚整个系统是如何设计的。佐证本仓库系列中可视化搭建/271.可视化搭建内置 API.md 正是逻辑层能力 5的具体展开——围绕组件树核心概念设计了addComponent、deleteComponent、setProps、undo/redo等 API且全部以组件 ID 为参数、内部转为组件树操作并内置 O(1) 时间复杂度的映射优化。而 可视化搭建/279.自动批处理与冻结.md 中冻结能力则与能力 5中性能优化诉求一一对应。逻辑层存在的必要性五个绕不开的通用问题回到问题根源对逻辑层做统一抽象到底是不是多余的我们手头的工具其实很充分基础开发工具 html、js、csshtml 还提供了标准化的 xml 结构vue、react 等开发框架、基础组件、应用生命周期与事件定义。理论上基于这些就可以直接上手写一个可视化搭建平台似乎可以不抽象。但真正动手时一定会遇到以下五个通用问题。1. 定义组件树结构无论做表单搭建、报表搭建、大屏搭建还是脑图画布第一个想到的问题一定是如何描述画布结构而无论画布横排还是竖排横竖都是一棵树。但HTML 树不能直接搬过来原因有二HTML 树的完整结构太大而我们需要的结构更精简业务层框架一般先有一套虚拟树再转化为 dom 树因果关系没法反过来。这棵树可以做到最大程度的抽象即只定义组件 ID、组件名、属性Props、子节点。本系列后续在 可视化搭建/269.组件注册与画布渲染.md 中落地为ComponentInstance结构{ componentName: container, children: [ { componentName: text, props: { name: 我是一个文本组件 } } ] }三个核心要素缺一不可componentName描述组件类型没有它无从渲染props承载该实例的全部配置透传给组件children描述子组件建议同时支持children与props.children两种位置同时定义时前者优先级更高。可选属性componentId用于组件移动后保持唯一性因为组件树路径如children.0是天然 ID但移动后会失效。2. 定义对组件树增删改查函数有了组件树肯定需要对其进行增删改查操作。因为无法基于 document API上层框架如 vue、react 也不提供对任何标准组件树的增删改查 API这部分能力势必要手动实现。本系列在 可视化搭建/271.可视化搭建内置 API.md 中给出了完整答案以setComponentTree()为底层基石派生出addComponent()、deleteComponent()、getComponent()、setComponent()、setProps()等便捷 API。核心 API 只有寥寥几个其余 API 都以便利性为目的、以核心 API 为基础实现这样框架核心更稳定。3. 生命周期假设完全依赖 React 框架提供的组件生命周期可以完成大部分业务逻辑但这意味着定义不够精细化。比如在组件 Mount 时实际监听联动、实现取数、设置冻结等效果虽然也能实现但会遇到要不要抽象的问题如果不抽象业务代码乱糟糟的比较难读。如果抽象就要把联动、取数、冻结等模块归类封装成函数甚至可以提供主动调用机制让 UI 与逻辑解耦。但业务层精细地去做这件事时就会发现——这就是在做框架层的抽象工作所以还不如一开始就把这些生命周期抽象到框架里。逻辑层有两个核心结构组件树结构对每个组件实例的定义与组件元信息结构对每个组件的元信息描述。逻辑层的难点在于元信息定义足够多、足够通用的生命周期回调函数且这些回调函数还能尽可能功能正交。佐证本系列把生命周期落到了组件元信息的各个回调钩子上——可视化搭建/273.组件值与联动.md 的valueRelates、可视化搭建/274.定义联动协议.md 的runtimeProps、可视化搭建/275.组件值校验.md 的valueValidator、可视化搭建/279.自动批处理与冻结.md 的fetcher/init等。它们彼此正交、互不感知正是功能正交设计目标的具体体现。4. 组件渲染通常一棵树按 json 结构自顶向下自动渲染即可但存在特殊场景比如内嵌一个富文本组件而富文本内又嵌入一些画布组件这些组件需要像普通画布组件一样可交互。此时就有了渲染一个不存在于组件树的组件实例的需求而这样的动态组件又要无感知地满足上述各类生命周期这也是不小的工作量。佐证该问题在 可视化搭建/278.ComponentLoader 与动态组件.md 中得到解决——ComponentLoader支持按组件 ID 加载componentId、按组件树路径加载treePath如children.0以及standalone动态组件三种用法且Canvas /根节点本质上等价于ComponentLoader treePath /。5. 功能的拓展抽象等可视化搭建平台正式维护时至少会遇到三类需求组件版本升级、不同类型的布局方案对接、三方组件注册。这些功能如何加入到现有平台而不让其他功能感知需要精心设计。如果逻辑层把这一点抽象好——在每个功能设计一个钩子实现一个功能时无需感知其他功能——平台的功能拓展就会保持恒定速度不随功能增加而变得难以维护。佐证本系列在 可视化搭建/270.画布与组件元信息数据流.md 中提供了统一的数据流拓展入口通过createDesigner()创建上下文隔离的Designer/Canvas/useDesigner业务可自由注册actions与state受控模式或用createMiddleware自定义中间件非受控模式。所有定义的状态与方法无论在内置函数还是组件元信息回调中都能统一访问这正是功能拓展不感知其他功能的落地。可见可视化搭建不断迭代的过程就是自身不断抽象的过程。逻辑层实现的好坏直接影响到后期的维护性与拓展性所以好好设计逻辑层可以让开发事半功倍。组件配置表单要不要用搭建方案做组件配置直接用表单方案而不是搭建似乎是最容易想到的。但当每个组件都要自定义配置我们就不得不选择基于 JsonSchema 描述的表单方案而这与搭建应用本身的技术栈割裂了。随着联动功能要求越来越多会越来越发现小小的表单渲染引擎维护得越来越复杂甚至复杂度与画布不分上下此时再叹息两边技术栈不统一就已经晚了。换个角度想搭建应用不也要考虑组件间联动吗从表单值能力来看搭建场景并不要求每个组件都拥有一个值反倒是可以将组件任意 props 属性看作表单值这样更具有弹性——我们可以拓展任意 Key 作为表单值。另外从数据结构出发描述表单看似很美好但当表单变得越来越复杂、UI 越来越定制后势必引入新的 UI 节点或新的结构描述。与其后期拓展到一个不纯净的 JsonSchema 结构不如一开始就放弃这个幻想用 UI 组件树结构描述表单。这样事情就变得简单了先描述组件树再定义每个节点分别用什么组件渲染响应表单的哪部分 Key。佐证本系列在 可视化搭建/270.画布与组件元信息数据流.md 中确实做到了用一套技术方案同时实现画布与配置表单——通过createDesigner创建一套上下文独立的 API画布、配置面板都可以用 Designer 实现学习上下文与组件规范统一为一套表单与画布能力共享。总结回到主题抽象可视化搭建的方法是分层以逻辑层打底提供一套标准规范与 API 接口上层注册组件、实现布局一切围绕着标准化的逻辑层进行拓展。两条实践建议值得铭记分层 单测可视化搭建的每一层都可以分别写单元测试保证最终变化的代码只有业务层的对接部分应用的稳定性随之提高。正交的 API 设计如果一个功能被设计为钩子实现时无需感知其他功能那么无论后续叠加组件版本升级、布局方案对接还是三方组件注册平台的拓展速度都能保持恒定。最后留一个思考题你觉得可视化搭建应该如何抽象如果想要做到每一层独立正交你会如何设计 API带着这个问题去研读本仓库可视化搭建系列接下来的篇章组件注册与画布渲染、画布与组件元信息数据流、可视化搭建内置 API、组件值与联动、定义联动协议、组件值校验、keepAlive 模式、ComponentLoader 与动态组件、自动批处理与冻结你会看到一套完整的抽象落地路径——从本文的逻辑层理论到 可视化搭建/269.组件注册与画布渲染.md 的组件树与组件元信息两个核心概念再到 可视化搭建/270.画布与组件元信息数据流.md 中数据流、组件元信息、组件实例的铁三角设定直至 可视化搭建/280.场景实战.md 的综合演练。赞分享文档技术博客教程【免费下载链接】weekly前端精读周刊。帮你理解最前沿、实用的技术。项目地址https://gitcode.com/GitHub_Trending/we/weekly点击查看免费下载相关推荐30 分钟搭好一个 ESP32 温湿度光照监测节点硬件不到 150 元30 分钟搭好一个 ESP32 温湿度光照监测节点硬件不到 150 元 昨晚回家卧室又闷又干空调到底有没有在制热、绿植盆土干了没有全靠感觉。这类人不在嵌入式物联网驱动开发Higress 插件生态指南7 个热门社区扩展快速上手Higress 插件生态指南7 个热门社区扩展快速上手 本文基于开源项目 HigressAI Native API Gateway面向新手推荐并讲解 7API网关后端云原生LLM 网关人工智能MCP 服务深入解析Video2X基于机器学习的视频超分辨率与帧插值框架终极指南深入解析Video2X基于机器学习的视频超分辨率与帧插值框架终极指南 Video2X是一个基于机器学习的高性能视频超分辨率和帧插值框架能够将低分辨率视频无损音视频视频处理图像处理深度学习上一篇grill-with-docs 实战指南一次会话完成设计对齐与领域文档沉淀下一篇Vegile工具深度解析Linux后渗透时代的幽灵进程守护者创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考