关于前端:低代码页面搭建平台在百瓶的实践

前言

大家好，我是本次内容的分享人君二，明天我要讲的主题是「低代码页面搭建平台在百瓶的实际」。接下来就带大家理解一下咱们为什么要做这样一个零碎，以及咱们是如何胜利实现这个零碎的。

咱们的低代码零碎服务于咱们公司的产品——百瓶 APP，它是一个业余的威士忌社区，大家如果想分享喝酒的日常、买酒卖酒都能够上咱们的 APP。

咱们在实现业务方面向 C 端用户的需要时，发现大量电商推广页面的逻辑复杂度和交互水平都比拟低，但却要耗费大量的开发资源。同时在后盾管理系统的开发过程中，咱们也发现一些雷同套路的页面在不同场景下须要反复开发，即便咱们封装了开箱即用的业务组件，也难逃老本不低的心智累赘。

因而，在调研了市面上一些解决方案后，咱们决定搭上低代码这趟高铁。

传统模式的痛点

咱们在设计零碎时肯定不能脱离业务，自嗨并不能为咱们带来真正的价值，因而咱们首先要晓得在做这个零碎之前，咱们的效率瓶颈在哪些地方。在传统模式中，不论是瀑布式开发还是麻利式开发，都逃不过需要从经营或产品方提出，而后通过一系列开发、测试再到上线。

咱们可否省去开发、测试、运维这些环节？

挪动端

在开发挪动端电商推广页时，咱们要达成疾速交付、低保护老本的成果。此时，咱们通常会对页面进行充沛的组件化，比方图片组件、文本组件、商品列表组件、优惠券组件等，然而即使这么做了，咱们开发测试一个页面也可能要花费两到三个人力的一天左右的工夫。

此外，为了应答经营随时更改经营策略、调整页面布局，咱们可能会在后盾管理系统中减少诸多配置，然而即便如此，仍然不能涵盖所有的保护场景。

治理后盾

除了挪动端页面外，咱们在开发后盾管理系统的页面时也有诸多痛点。家喻户晓，后盾管理系统其实就是一个可视化的数据库，外面的内容万变不离其宗，无非是数据获取、数据展现、用户输出、管制校验、数据提交。这其中大部分的页面模式都是雷同的，如果咱们为了缩小开发工作量而抽离大量业务组件，也免不了这些业务组件的管制逻辑开发以及记忆负担。而如果咱们持续封装出业务性更强的开箱即用组件，就会产生自由度不够高、组件属性越加越多等不易于定制和保护的景象。

平台设计思路

既然咱们决定要向低代码的方向倒退，在踏出这一步之前咱们就必须思考分明，咱们是对开源我的项目进行革新还是齐全自研。我认为这个问题须要依据理论状况而定。

如果你要做的我的项目更偏重展现，并且在将来只会退出大量个性化的内容，那我倡议寻找一个优良的低代码开源我的项目进行革新，市面上有诸如 h5-Dooring 这样优良的挪动端低代码平台，也有 Ant Design Landing 这样根本不须要开发的 PC 端低代码平台。

反之，自研会更好。

需要收集

自研前的筹备须要尽可能地详尽充沛，毕竟咱们谁也不想写到一半把计划推倒重来。

百瓶的页面搭建零碎在布局以及操作模式上模拟了 h5-Dooring 我的项目，左侧是组件库，两头是画布，右侧是配置属性。此外，咱们还须要布局组件库以及组件对应的配置，设计数据结构，拆分整个闭环的各大模块，设计模块的细节等等。

在不同端上，页面布局模式会有比拟大的差别。

• 挪动端页面在布局时因为横向尺寸较小，偏差于楼层式布局，偶然会有多数悬浮组件；
• PC 端页面在布局时因为整体尺寸较大，更偏差于自在布局，得心应手。

在举荐应用哪种形式之前分享一下咱们在实际过程中 踩的坑。

起初咱们抉择了楼层式的高低重叠布局，起因是挪动端页面布局简略，经营只须要叠加图片、文字、商品列表、超链接等组件就能实现某一次的促销。尽管咱们预见到了未来可能会有组件套组件的状况产生，然而并没有器重。而后 618 降临了，京东、淘宝这些大型电商平台目不暇接的会场页给了咱们一个惨重的打击。咱们的搭建零碎做不到那种水平，基本就无奈反对页面中有标签栏或导航栏这样的容器组件存在。618 过后咱们不得已应用了一种极不优雅的形式解决组件嵌套的问题，保护和操作老本昂扬。

之后，咱们在开发面向开发的后盾可视化搭建零碎时，赌咒绝不吃一堑; 长一智。这次抉择了比较复杂的自在布局，采纳树形构造示意组件间的关系，这才领会到「自在布局真香」。

所以要尝试可视化搭建的小伙伴，给你们一个忠告：不要犹豫，间接上自在布局！

除了面向不同设施须要有不同的设计，面向不同的使用者也须要思考零碎要做到什么水平。就拿组件库品种和组件配置来说。

• 当零碎面向经营人员，那么组件须要尽可能地业务化，缩小使用者的认知老本，包含组件的配置，以通俗易懂的名词为主，并且整体配置数量要尽可能精简；
• 当零碎面向开发人员，那么组件须要尽可能地原子化，减少使用者的自由度，组件配置也须要尽可能地细化，以代码中呈现的名词为主，并且配置项在需要范畴内要尽可能具体。

渲染根据的确定

驰名的 Pascal 之父说过一句话：程序 = 数据结构 + 算法，我认为数据结构该当先于算法设计，数据结构在很大水平上会决定算法的走向。因而开始正式编写设计方案时，我抉择从数据结构的设计开始。

咱们在搭建完一个页面之后，理论导出后果大抵有两种方向。

• 导出 DSL 形容文件；
• 导出页面源代码。

形容文件的长处是：

• 渲染无关：它不关怀渲染器是如何实现的，你用 Vue 也好 React 也好都没问题，每个组件的渲染成果都由组件本人治理，能够做到主题切换、构造动态化、千人千面等成果；
• 不便部署：因为它只是页面构造的形容，在渲染器是现成的状况下，它可能在页面搭建结束后间接进行线上公布，无需构建；
• 二次编辑：因为它与渲染无关，形容文件始终不变，因而它能够很不便地进行二次解析与编辑。

然而它也有一个显著的毛病：

• 二次开发艰难：如果咱们碰到了组件库或者行为库中不存在的个性化需要，就须要二次开发，而应用形容文件就很难进行自定义组件的插入或是管制逻辑自定义。

间接导出源代码除了二次开发不便外，我感觉毛病占大多数：

• DevOps 老本升高：从搭建结束到构建部署的自动化链路须要投入更多精力；
• 老数据不易解决：渲染框架更换后，解决老数据极其简单；
• 二次编辑老本升高：对源代码进行页面二次编辑时须要借助语法分析，生成 AST 树或其它树形数据结构来复原现场，这个操作须要团队有更多的人力老本与试错机会。

咱们抉择了第一种以 DSL 形容文件作为页面导出的根底，为了解决自定义组件和自定义逻辑注入的问题，咱们采纳了自定义插槽组件以及上下文逻辑调用的形式，在肯定水平上实现了鱼和熊掌兼得。

BBCS 全景

实现数据结构的设计之后，咱们对模块进行了一个大略的拆分。整个零碎由几大重要模块形成：

• 编辑器
• 自在布局零碎
• 行为核心零碎
• 数据中心零碎
• 渲染器

编辑器负责了组件库的出现、自在布局模式的搭建、组件的配置、虚构数据中心的形容以及逻辑编排。

渲染器负责了依赖自在布局的组件渲染、编排逻辑的执行以及数据流转的调度。

数据中心是最外围的模块，它保留了页面运行时的数据状态，组件在运行时无论是读取数据进行展现还是存储用户输出数据，都是通过数据中心进行的。

行为核心是交互时的重要依仗，因为咱们的零碎不仅须要反对页面布局构造的搭建，也要能进行逻辑编排。编辑器的逻辑编排系统生成的行为形容文件，将由渲染器的行为调度器执行具体逻辑。

整个闭环大略是这样的：

1. 在编辑器中通过接口返回数据结构或其它须要半自动化构建出虚构数据中心形容；
2. 捋清页面须要的逻辑，进行逻辑编排，并将原子逻辑的输入输出数据字段与虚构数据中心正确地关联；
3. 进行页面构造的搭建，正确地将组件的输入输出数据字段与虚构数据中心关联，并在须要时将组件事件与行为（编排的逻辑）挂钩；
4. 实现页面编辑，挪动端间接上传形容文件至服务器，治理后盾导出形容文件至指标我的项目以便反对二次开发；
5. 渲染器接管服务端返回的形容文件或我的项目中动态的形容文件进行渲染。

如何实现自在布局

后面咱们重点提到了自在布局的益处，那它应该如何实现呢？

在编辑器层面，如果有比拟适宜自身产品状态的三方拖拽解决库等现成的解决方案，那强烈建议间接应用，不必反复造轮子。咱们抉择了本人解决拖拽事件来实现自在布局，要点就是解决好拖拽事件的拦挡与落点地位的计算。咱们在编辑器中对自在布局做了这些操作：

• 设置组件库和画布中的组件使之可被拖拽；
• 组件被拖拽时保留组件的信息；
• 画布中的组件接管并拦挡拖拽挪动事件，在全局状态中保护本身与事件触发地位信息；
• 依据以后拖拽达到的组件类型（容器与非容器型）与事件触发地位计算落点地位并在画布中有所示意；
• 拖拽放下时依据计算的落点地位正确地解决组件的创立插入或挪动。

在渲染器层面，递归地渲染组件是一件很容易的事，然而须要重点解决好每一个组件的上下文信息，上下文信息极其重要 ，组件所需的渲染数据可能就来源于这些上下文信息而不只是数据中心，比方表格中的 行数据！

为什么是数据中心

在架构图中，比拟让人困惑的应该是数据中心和行为核心了，那数据中心是什么呢？

简略地讲，它就是一个响应式对象，组件渲染时须要用到的数据就从它外面取，向内输出的数据比方用户输出也存到它体内，当然行为须要的数据比方接口调用入参的起源也是它。

红色的这个小图是我从咱们零碎中图片展现组件的配置中截进去的，它配置了图片展现数据的起源，来自数据中心的 row 对象的 cover 字段。数据中心通过链式字段名和视图以及行为的数据绑定产生关联。

右边这张彩色的大图是数据中心的繁难实现，咱们须要将数据中心打造成响应式以确保数据驱动页面能顺利进行。

为什么打造数据中心？因为通常咱们页面渲染及其他数据是寄存于页面状态或全局状态中的，当咱们要对页面进行渲染以及逻辑解决时，就必须将数据的流转思考进去。数据的次要起源是接口和用户输出，页面配置是动态的，接口和用户输出是运行时的，要将这两者有机关联，并且要求低耦合，比拟好的形式就是将行为产生的接口数据送入数据中心，由组件本人拿取。

这样就做到了存数据和取数据两个动作的执行者互相是黑盒的，取数据的人并不知道数据是谁存进去的，存数据的人也并不知道我存的这份数据到底给谁用。因而，这种设计形式很好地实现了动态配置与运行时状态的有机联合。

行为核心是什么

咱们总须要一个中央去管制数据中心的数据流转，数据中心没有数据起源也没有数据去向的话就是无用设计。就像我上文讲的，咱们不仅要对页面构造进行可视化搭建，也须要对数据逻辑进行可视化搭建。行为核心就是让咱们能够定义组件行为的中央。

上图中大家能够看到左侧那个小图是我从按钮组件的配置中截进去的，意思就是按钮的点击事件绑定了名为「搜寻」的行为。这张大图展现的就是行为编排时的界面，左侧是行为库，两头是行为编排画布，右侧是行为的配置。

有了行为核心后，咱们对逻辑的管制就比拟不便了，通过它咱们能实现页面初始化的时候进行数据获取并展现、点击按钮时收集表单数据并申请接口等等。

在编辑器层面，行为核心的逻辑编排应用了 AntV G6 引擎进行渲染，输入的数据结构也是参照了 AntV G6 的输出数据结构。

在渲染器层面，行为核心在收到执行某个行为组的信号之后，会寻找这个行为组中的起始节点，而后依据起始节点的不同类型（接口申请、提醒、比拟等）执行不同的逻辑，执行结束后会寻找节点的下一个关联节点继续执行，直到整条链路的逻辑执行结束。

落地与实际

通过大概每个零碎 3 月 / 人的开发，最终挪动端搭建零碎反对了 150+ 经营页面 99% 的搭建需要，治理后盾搭建零碎大概节俭了 50% 的开发成本。

不过咱们的计划也有毛病，有不少货色须要约定俗成，尽管有文档辅助，然而免不了认知上有差别。并且因为零碎稍稍有些宏大，所以第一次开发的老本会比拟高，不过要先忍住痛，当前能力舒坦。

如果大家的团队也有尝试的想法，我强烈建议先思考它是否真正为团队带来价值，是否真正解决大部分痛点，再确保有牢靠的人、充沛的工夫和欠缺的技术计划。

这是咱们治理后盾搭建零碎工作台的截图，得益于自在布局、行为核心和数据中心的联合，各种模式的后盾治理页面，比方列表页、表单页、详情页都能轻松反对。在后盾管理系统中万变不离展现型组件和输出型组件。

截图中正在搭建的是后盾管理系统的列表搜寻页。列表页中的搜寻条件区域其实就是个表单模块，各个输出组件将用户输出的数据送入数据中心，当点击搜寻按钮的时候就由搜寻行为从数据中心拿取用户输出并调用接口，接口调用胜利后由接口行为将数据存入数据中心，数据中心的响应性使得页面中的表格局部产生同步的展现更新。

将来布局

目前咱们还只进行到了低代码畛域的初级阶段，还须要逐渐迭代向零代码甚至智能化进发。

咱们下一步的打算就是尽可能减少罕用的模板组件与不同场景的页面模板以缩小从头搭建页面的老本。此外咱们将从实际中体验搭建零碎的有余，尽可能进步它的自动化水平和组件库丰盛度。

参考

1. 国内低代码平台从业者交流平台：https://github.com/taowen/awe…
2. h5-Dooring：https://github.com/MrXujiang/…
3. GrapesJS：https://github.com/artf/grapesjs
4. AntV G6：https://g6.antv.vision/zh
5. Ant Design 设计价值观：https://ant-design.gitee.io/d…

更多精彩请关注咱们的公众号「百瓶技术」，有不定期福利呦！