前言大家好，我是本篇内容的分享者，Jun2今天要讲的话题是《白屏低代码页面构建平台实践》.下面我就带大家了解一下我们为什么会有这样一个系统，以及我们是如何成功完成这个系统的。我们的低代码系统服务于我们公司的产品——百博APP，这是一个专业的威士忌社区。如果你想分享你喝酒、买酒、卖酒的日常，你可以使用我们的APP。当我们在业务上满足C端用户的需求时，发现大量的电商推广页面逻辑复杂度相对较低，交互程度较低，却消耗了大量的开发资源。同时，在开发后台管理系统的过程中，我们也发现一些套路相同的页面需要在不同的场景下重复开发。即使封装了开箱即用的业务组件，也难逃高成本的心理负担。因此，在考察了市面上的一些解决方案后，我们决定乘坐低码高铁。传统模式的痛点我们在设计系统的时候一定不能脱离业务。自我放纵不能给我们带来真正的价值，所以在构建这个系统之前，我们首先要知道我们的效率瓶颈在哪里。在传统模式下，无论是瀑布开发还是敏捷开发，需求都不能脱离运营或者产品端，然后经过一系列的开发、测试，然后上线。能不能省去开发、测试、运维环节？在移动端开发移动电商推广页面时，我们需要做到快速交付和低维护成本。这时候我们通常会把页面完全组件化，比如图片组件、文字组件、商品列表组件、优惠券组件等等，但即使这样做，我们也可能需要两到三个人力来开发和测试一个大约一天的页面。另外，为了应对随时改变运营策略和调整页面布局，我们可能会在后台管理系统中加入很多配置，但即便如此，仍然无法覆盖所有的维护场景。除了管理后台的移动端页面，我们在开发后台管理系统的页面时也有很多痛点。众所周知，后台管理系统其实就是一个可视化的数据库，里面的内容永远都是一样的。无非就是数据获取、数据展示、用户输入、控件验证、数据提交。大多数页面表单都是相同的。如果我们为了减少开发工作量而抽取大量的业务组件，那么这些业务组件的控制逻辑开发和内存负担就不可避免地会被避免。但是，如果继续封装更面向业务的开箱即用的组件，就会出现自由度不够，组件属性越来越多，不易定制和维护等现象。平台设计思路既然决定往低代码方向发展，那么在迈出这一步之前一定要想清楚，到底是改造开源项目，还是完全自研。我觉得这个问题需要根据实际情况来定。如果你要做的项目比较偏重于展示，以后只会加入少量的个性化内容，那我建议找一个优秀的低代码开源项目进行改造。市面上有h5-Dooring等优秀的移动端低代码项目，也有AntDesignLanding等基本不需要开发的PC端低代码平台。相反，自学会更好。需求收集和自研前的准备工作要尽可能详细、充分。毕竟我们谁也不想写到一半就推翻计划。百屏的页面构建系统在布局和运行形式上模仿了h5-Dooring项目，左边是组件库，中间是画布，右边是配置属性。此外，我们还需要规划组件库和组件的相应配置，设计数据结构，拆分整个闭环的主要模块，设计模块的细节等等。在不同的终端上，页面布局形式会有很大的不同。由于横向尺寸较小，移动页面的布局趋向于落地式布局，偶尔会有少量浮动组件；PC端页面布局由于整体尺寸较大，更倾向于自由布局。在推荐使用哪种方法之前，先分享一下我们在实践中踩过的坑。一开始，我们选择了落地式的堆叠布局。原因是移动端页面布局简单，操作只需要叠加图片、文字、商品列表、超链接等组件就可以达到一定的推广效果。虽然我们预见到以后可能会出现组件套组件的情况，但是我们并没有关注到。随后618来了，京东、淘宝等大型电商平台琳琅满目的会场页面给了我们沉重的打击。我们的构建系统无法做到这一点，它根本无法支持页面中标签栏或导航栏等容器组件的存在。618之后，我们不得不用一种极其不优雅的方式来解决组件嵌套的问题，维护和运维成本都很高。后来，在开发面向开发的后台可视化搭建系统时，我们发誓不再重蹈覆辙。这次我选择了比较复杂的自由布局，用树状结构来表示组件之间的关系，这才体会到“自由布局真香”。所以想尝试可视化搭建的朋友，奉劝大家：不要犹豫，直接上freelayout！除了针对不同的设备有不同的设计之外，还需要考虑系统应该在多大程度上针对不同的用户进行设计。以组件库类型和组件配置为例。当系统面向运营商时，组件需要尽可能面向业务，以降低用户的认知成本，包括组件的配置。人员，那么组件需要尽可能的原子化，增加用户的自由度，组件的配置也需要尽可能的详细，主要是代码中出现的名词，配置项在要求的范围。渲染基础的确定著名的Pascal之父说过一句话：程序=数据结构+算法，我认为数据结构应该先于算法设计，数据结构将在很大程度上决定算法的方向。所以在开始正式写设计方案的时候，我选择从数据结构的设计入手。我们搭建好页面后，实际的导出结果大致有两个方向。导出DSL描述文件；导出页面源代码。描述文件的优点是：渲染无关：它不关心渲染器如何实现它。使用Vue还是React并不重要。每个组件的渲染效果由组件自己管理，可以实现主题切换和结构动态、千面等效果；部署方便：因为只是对页面结构的描述，如果渲染器是现成的，可以在页面构建完成后直接发布到线上，无需构建；二次编辑：由于与渲染无关，描述文件一直都是一样的，所以可以方便的再次分析和编辑。但它也有一个明显的缺点：二次开发困难：如果我们遇到组件库或行为库中不存在的个性化需求，则需要进行二次开发，很难使用描述文件插入或自定义自定义组件。是控制逻辑定制。直接导出源码除了方便二次开发，缺点我觉得占了大部分：DevOps的成本增加：从构建完成到构建部署的环节自动化需要付出更多的努力；旧数据不易处理：更换渲染框架后，处理旧数据极其复杂；二次编辑成本高：二次编辑源代码时，需要通过语法分析生成AST树或其他树形数据结构来还原站点。这个操作需要团队有更多的人力成本和试错的机会。我们选择第一种方式，基于DSL描述文件作为页面导出的依据。为了解决自定义组件和自定义逻辑注入的问题，我们采用了自定义槽组件和上下文逻辑调用的方式，在一定程度上实现了鱼与熊掌兼得。BBCSPanorama完成数据结构的设计后，我们大致拆分了模块。整个系统由几个重要的模块组成：编辑器自由布局系统行为中心系统数据中心系统渲染器编辑器负责组件库的渲染、自由布局表单的构建、组件的配置、虚拟数据中心的描述和逻辑安排。渲染器负责依赖自由布局的组件的渲染、编排逻辑的执行、数据流的调度。数据中心是核心模块，保存页面运行时的数据状态。无论是组件在运行时读取数据进行显示还是存储用户输入的数据，都是通过数据中心完成的。行为中心是交互的重要基础，因为我们的系统不仅需要支持页面布局结构的构建，还需要能够进行逻辑排列。编辑器的逻辑编排系统生成的行为描述文件，会被渲染器的行为调度器执行。整个闭环大致是这样的：在编辑器中，通过虚拟数据中心描述的接口或者其他半自动构建的方式返回数据结构；理清页面所需的逻辑，对逻辑进行编排，将原子逻辑的输入输出数据字段与虚拟数据中心正确关联；构建页面结构，将组件的输入输出数据字段与虚拟数据中心正确关联，必要时将组件事件与行为（编排逻辑）联系起来；完成页面编辑，移动端直接上传描述文件到服务器，在管理后台导出描述文件到目标项目，支持二次开发；渲染器接收服务器返回的描述文件或项目中的静态描述文件进行渲染。如何实现自由布局前面我们已经提到了自由布局的好处，那么应该如何实现呢？在编辑器层面，如果有现成的解决方案比如三方拖拽处理库更适合自己的产品形态，强烈建议直接使用，不用重新造轮子。我们选择自己处理拖动事件，实现自由布局。重点是处理拖拽事件的拦截和拖放位置的计算。我们在编辑器中对自由布局做了这些操作：将组件库和画布中的组件设置为可拖动；拖动组件时保存组件信息；画布中的组件接收并拦截拖拽移动事件，在全局状态中维护自身和事件触发的位置信息；根据当前拖动的组件类型（容器和非容器类型）和事件触发位置计算出落点位置并在画布中表示；根据计算出的拖放点位置正确处理组件的创建插入或移动。在渲染器层面，很容易递归渲染组件，但是需要关注每个组件的上下文信息。上下文信息非常重要。组件所需要的渲染数据可能来自于这些上下文信息而不仅仅是数据中心，比如表格中的行数据！架构图中为什么是数据中心，比较容易混淆的应该是数据中心和行为中心，那么什么是数据中心呢？简单地说，它是一个响应式对象。组件渲染需要的数据就是从它里面取出来的，输入到它里面的数据，比如用户输入，也存储在里面。当然，行为所需要的数据，比如接口调用的入参，来源也是它。小白图是我们系统中图片显示组件的配置中截取出来的。配置图片显示数据的来源，来自数据中心行对象的cover字段。数据中心通过链式字段名称和视图和行为的数据绑定进行关联。左边的黑色大图是数据中心的简单实现。我们需要让数据中心响应迅速，以确保数据驱动的页面能够顺利进行。为什么要建设数据中心？因为通常我们的页面渲染等数据都保存在页面状态或者全局状态中，所以当我们要对页面进行渲染和逻辑处理时，就必须考虑到数据的流向。数据的主要来源是界面和用户输入。页面配置是静态的，界面和用户输入是运行时的。要将两者有机的联系起来，要求低耦合，更好的方式是将行为产生的接口数据发送到数据中心，由组件自己拾取。这样存数据和取数据两个动作的执行者互为黑盒。取数据的人不知道谁存了数据，存数据的人不知道我存的数据。为了谁。因此，这种设计方法实现了静态配置和运行时状态的有机结合。什么是行为中心？我们总是需要一个地方来控制数据中心的数据流。如果数据中心没有数据源，也没有数据目的地，那就是无用的设计。正如我上面所说，我们不仅需要将页面结构可视化，还需要将数据逻辑可视化。行为中心是我们可以定义组件行为的地方。上图中，可以看到左边的小图是从按钮组件的配置中截取下来的，也就是说按钮的点击事件绑定了名为“搜索”的行为。这张大图是行为编排的界面，左边是行为库，中间是行为编排画布，右边是行为配置。有了行为中心，我们对逻辑的控制就更方便了。通过它，我们可以在页面初始化时获取并显示数据，在点击按钮时收集表单数据和请求接口等等。在编辑器层面，行为中心的逻辑布局使用了AntVG6引擎进行渲染，输出数据结构也参考了AntVG6的输入数据结构。在renderer层面，行为中心收到执行某个行为组的信号后，会在行为组中寻找起始节点，然后根据起始节点的不同类型执行不同的动作（接口请求，提示、比较等）。逻辑，执行完成后，会找到该节点的下一个关联节点继续执行，直到执行完整个链路的逻辑。落地实践经过每人每系统约3个月的开发，移动端搭建系统最终支持了150+运营页面99%的搭建需求，管理后台搭建系统节省了约50%的开发成本。但是，我们的解决方案也有缺点。有很多事情需要达成一致。虽然有文献辅助，但认知上难免会有差异。而且因为系统有点庞大，所以第一次开发的成本会比较高，但是你要先忍痛，后面才能舒服。如果你的团队也有尝试的想法，我强烈建议考虑一下是否真的能给团队带来价值，是否真的能解决大部分痛点，然后保证人靠谱，时间充足和完善的技术解决方案。这是我们管理后台搭建系统工作台的截图。通过自由布局、行为中心和数据中心的结合，可以轻松支持列表页、表单页、详情页等多种形式的后台管理页面。在后台管理系统中，总有显示组件和输入组件。截图中正在搭建的是后台管理系统的列表搜索页面。列表页的搜索条件区其实就是一个表单模块。每个输入组件将用户输入的数据发送到数据中心。单击搜索按钮时，搜索行为会从数据中心获取用户输入并调用接口。接口调用成功。之后通过接口行为将数据存储到数据中心，数据中心的响应能力使得页面中的表格部分同步显示和更新。未来规划目前我们在低代码领域才刚刚起步，需要逐步向零代码甚至智能方向迭代。我们接下来的计划是尽可能增加通用的模板组件和不同场景的页面模板，以降低从头开始构建页面的成本。另外，我们将从实践中体会到构建系统的不足，并尽可能地提高其自动化程度和组件库的丰富度。参考国内低代码平台从业者交流平台：https://github.com/taowen/awe...h5-Dooring：https://github.com/MrXujiang/...GrapesJS：https://github。「百瓶科技」，还有不定期福利哦！
