关于前端:精读如何抽象可视化搭建

在做任何可视化搭建我的项目时，第一步都要思考如何形象。

如果不形象，当搭建我的项目做到前期可能会呈现 API 芜杂，难以保护的问题；做到一半甚至会狐疑为什么须要一个搭建框架，狐疑把框架去掉会不会效率更高；在前期发现不能天然的程度拓展到仪表盘、大屏、表单搭建场景等。

所以如果在保护一套可视化搭建零碎时，不论这个零碎的下层是 BI、大屏、表单填报，还是脑图也好，无论是什么，都要先思考一下这些零碎背地的底层是什么，需不需要形象，形象的意义和价值在哪。

以下联合笔者的教训，尝试给出一种思考角度。

精读

什么是可视化搭建

表单搭建、中后盾利用搭建、BI 仪表盘搭建、大屏搭建都算可视化搭建，因为它们都是在一个画布上拖拖拽拽实现的。

那么组件配置表单算搭建吗？聚焦单组件剖析的可视化摸索呢？幻灯片呢？

比方组件配置表单，它基于 UI 组件树形象的话，就是可视化搭建，但如果基于表单构造形象，就是 JsonSchema，但真的所有业务场景都是数据齐全映射 UI 吗？不肯定，因为 UI 能够为了用户操作不便而退出更多辅助元素，甚至把一个属性拆成多个 UI 填写，所以基于可视化搭建，也就是 UI 组件树形象的肯定能够笼罩所有表单场景，但不肯定是形容效率最高的形式。

如果每种可视化搭建场景都定义一套协定与实现，那依照搭建平台的复杂度，想同时保护两个类搭建平台的老本肯定是两倍，而且不同保护人员很难交换。又或者某些能够依照搭建思路解决的场景，因为实现时经验不足，没有进行形象，甚至进行了另一套定制形象，回过头来看可能积重难返，团队不得不承受多套轻便实现的现状。

所以倡议将这些场景都视为可视化搭建场景，用一套接口形容构造、API 办法，让看似百花齐放的编辑器之下领有对立的上下文与实现。

可视化搭建的分层

对于不同品种的可视化搭建平台，咱们尝试寻找其分层设计的最大公约数。如果把可视化搭建底层设定为逻辑层，即这个层是 UI 无关的，仅关怀组件树结构、逻辑性能，那么对于每种平台的分层应该是这样的：

1. 表单搭建：逻辑层、表单联动协定层、表单控件、业务层。
2. 中后盾利用搭建：逻辑层、利用联动协定层、利用控件、业务层。
3. BI 仪表盘：逻辑层、筛选联动协定层、可视化控件、业务层。
4. 大屏搭建：逻辑层、画布编辑控制器层、可视化控件和根底图形控件、业务层。

最底层的逻辑层应该能够对立所有类型搭建零碎，并成为开发人员对立上下文的。它能够蕴含以下根底能力：

1. 定义组件树结构。
2. 定义组件元信息。
3. 依照组件树结构递归渲染画布。
4. 反对布局、取数、联动、筛选、校验等一系列拓展能力，业务可依据须要定制。
5. 提供所有业务层都须要的能力，比方性能优化的组件解冻、状态治理、对组件树增删改查的 API。

在逻辑层齐备后，再开发下层利用就会轻松很多，只有注册组件、依据业务须要在组件树初始化或组件初始化，或组件元信息注册时增加定制逻辑，与零碎性能对接，并补充业务特色的如自定义布局能力，这样就能够用简略的喋喋不休说分明整个零碎是如何设计的。

逻辑层存在的必要性

再回到问题的本源：对逻辑层做对立的形象到底是不是多余的？

要答复这个问题，须要先理解咱们手头里有哪些工具：根底开发工具 html、js、css，并且 html 也提供了一套标准化的 xml 构造；vue、react 等开发框架，根底组件、利用生命周期与事件定义。实践上基于这些，咱们就能够间接上手写一个可视化搭建平台了，仿佛也能够不形象。但真正要上手时，肯定会遇到以下几个通用问题须要解决：

定义组件树结构

无论做表单搭建、报表搭建、大屏搭建还是脑图画布，第一个想到的必定是如何形容这个画布构造，而无论画布是横着排还是竖着排，横竖都是一棵树。HTML 树不能间接搬过去，一是 HTML 树的残缺构造太大而咱们须要的更精简的构造，二是业务层框架个别都先有一套虚构树再转化为 dom 树，因果关系也没法反过来。而这棵树也齐全能够做最大水平的形象，即定义组件 ID、组件名、属性（Props）、子节点。

定义对组件树增删改查函数

有了组件树必定须要对其进行增删改查操作，因为无奈基于 document API，下层框架如 vue、react 也不提供对任何规范组件树的增删改查 API，这部分能力势必要手动实现。

生命周期

假如齐全依赖 React 框架提供的组件生命周期，是能够实现大部分业务逻辑，但这意味着定义不够精细化。比方说，咱们在组件 Mount 的理论监听了联动、实现取数、设置解冻等等成果，尽管也能够实现，但会遇到要不要形象的问题：

• 如果不形象，业务代码就会乱哄哄的，比拟难读。
• 如果形象，就要把联动、取数、解冻等等模块归类，封装成函数，甚至能够提供被动调用机制，UI 与逻辑解耦，但当业务层精密的去做这件事就会发现，这就是在做框架层的形象工作，所以还不如一开始就把这些生命周期形象到框架里。

逻辑层有两个外围构造，第一个是组件树结构，蕴含了对每个组件实例的定义；第二个是组件元信息结构，蕴含了对每个组件的元信息形容，大略如下图所示：

<img width=400 src=”https://user-images.githubusercontent.com/7970947/211183628-75469a31-54cf-446a-9df8-a18bb41508db.png”>

逻辑层的难点就是在元信息定义足够多、足够通用的生命周期回调函数，并且这些回调函数还能尽可能的性能正交。

组件渲染

通常一棵树依照 json 构造形容自顶向下主动渲染就能够了，但也有一些时候，比方内嵌一个富文本组件，而富文本内又嵌入一些画布组件，这些组件须要像一般画布组件一样可交互，此时就有 渲染一个不存在于组件树的组件实例 的需要，而这样的动静组件又要无感知的满足下面所说的各类生命周期，这也是不小的工作量。

性能的拓展形象

等可视化搭建平台正式保护时，就至多会遇到组件版本升级、不同类型的布局计划对接、三方组件注册等需要，这些性能如何退出到现有的搭建平台，而不让其余性能感知，是须要精心设计的。如果逻辑层把这一点形象好，在每个功能设计一个钩子，实现一个性能时无需感知其余性能，那平台的性能拓展就会放弃一个恒定的速度，不随性能减少而变得难以保护。

可见，可视化搭建一直迭代的过程就是本身一直形象的过程，逻辑层实现的好坏间接影响到前期的维护性与拓展性，所以好好设计逻辑层能够让开发事倍功半。

组件配置表单要不要用搭建计划做

组件配置间接用表单计划而不是搭建，仿佛是最容易想到的。但当每个组件都要自定义配置，咱们就不得不抉择基于 JsonSchema 形容的表单计划，但这与搭建利用自身的技术栈割裂了，随着联动性能的要求越来越多，会越来越发现小小的表单渲染引擎保护得越来越简单，甚至复杂度与画布不分上下，此时再叹气两边技术栈不对立就曾经晚了。

换个角度想一下，搭建利用不也要思考组件间联动吗？从表单值能力来看，搭建场景并不要求每个组件都领有一个值，反倒是能够将组件任意 props 属性看作表单值更具备“弹性”，咱们能够拓展任意 Key 作为表单值。

另外，从数据结构触发来形容表单看似很美妙，但当表单变得越来越简单，UI 越来越定制后，势必引入新的 UI 节点或者新的构造形容，与其前期拓展到一个不污浊的 JsonSchema 构造，不如一开始就放弃这个空想，用 UI 组件树结构形容表单，这样事件就变得简略了：“先形容组件树，再定义每个节点别离用什么组件渲染，响应表单的哪局部 Key”。

总结

总结一下，回到主题，形象可视化搭建的办法是分层：以逻辑层打底，提供一套标准规范与 API 接口，下层注册组件、实现布局，所有围绕着标准化的逻辑层进行拓展。

而可视化搭建的每一层都能够别离写单元测试，保障最终变动的代码只有业务层的对接局部，利用的稳定性就进步了。

最初提一个思考题：你是感觉可视化搭建应该如何形象？如果想要做到每一层独立正交，你会如何设计 API 呢？

探讨地址是：精读《如何形象可视化搭建》· Issue #463 · dt-fe/weekly

如果你想参加探讨，请 点击这里，每周都有新的主题，周末或周一公布。前端精读 – 帮你筛选靠谱的内容。

关注 前端精读微信公众号

<img width=200 src=”https://img.alicdn.com/tfs/TB165W0MCzqK1RjSZFLXXcn2XXa-258-258.jpg”>

版权申明：自在转载 - 非商用 - 非衍生 - 放弃署名（创意共享 3.0 许可证）