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

46次阅读

共计 3390 个字符,预计需要花费 9 分钟才能阅读完成。

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

如果不形象,当搭建我的项目做到前期可能会呈现 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 许可证)

正文完
 0