基于低代码平台，如何设计平台级组件开发方案？

原创 katecjzheng 腾讯大讲堂

导语 | 从去年开始，我们团队一直在研发一款叫做“无极”的低代码产品。组件是低代码平台可视化布局的基础元素。作为低代码平台方，既要提供公共组件池，直接覆盖90%的组件场景；又要有灵活易用的组件开发方案，供多个业务开发自定义组件。下文我们将分享平台级组件相关的一些设计思路。

作者：katecjzheng 腾讯PCG前端工程师

背景

我们在研发的是一个to B的低代码平台。简单来说，就是利用可视化的方式，通过拖拽组件到画布中，结合数据源的绑定，用来生成管理台的工具。

实际上，管理台的模式相对固定，有大量同质化需求，套用低代码去实现最为合适。对于画布来说，组成UI的组件库就最为关键。目前我们提供了40个官方公共组件，能满足大部分管理台需求。

但业务方一定有定制化组件需求。而只要自定义组件的生产门槛有一点高，就会劝退使用方，甚至直接不使用整个平台。最理想的模式应该是，整个画布大块（甚至全部）的区域，能直接使用公共组件拖拽生成；而其中一些块，能够用自定义组件进行填充。既能完整地还原页面需求，又能减少重复开发工作（主要指平台的公共组件、接口调用、平台权限等），最大化获得使用低代码平台带来的收益。

而对于一个自定义组件，必须足够灵活。组件开发者可以选择将组件共享出来，供其他团队搭建管理台时直接使用。或者作为一个原子，供其他自定义组件套娃依赖使用。并且，组件最好跟项目相互独立，这样任意一个组件可支持跨项目进行复用。

对于低代码平台组件的设计，最关注以下两点：

1. 组件开发流程

目标：对齐原生组件开发体验，所见即所得。指的是，不需要发布组件后，才能看到组件在多个远程管理台多种场景的呈现效果。当然了，也不能出现太多"个性化"概念让开发者去理解（比如如何引用自定义组件，自定义属性面板等）。

2. 组件依赖管理

管理台中涉及大量组件包含组件的场景，所以会聊到组件在线上的版本策略问题。

平台级组件开发方式

1. 组件的基本构成

一个完整的组件，由组件本身的UI，以及属性面板构成。调试时两者需要联动，需要在组件UI上，实时看到对应的属性配置效果。

属性面板一般涉及到数据源、管理台页面等的绑定，需要跟平台功能互通。如考虑最最传统的组件开发模式：不提供宿主环境，直接开发一个组件，发布到平台使用。

总结：组件脱离平台进行开发，需要反复发布、线上验证才能达到预期效果。

2. 传统的组件开发模式 - 进阶版

那让用户直接使用平台代码进行开发，这样就有宿主环境了。

第一步，拉取平台代码

第二步，偷偷问平台管理员拿账号密码（平台级账号密码是保密的，不在代码中）

第三步，一翻折腾后把整个平台代码跑起来，终于想起来是为了开发一个小组件（这才是关键啊喂）...

作为一个平台方工具，DB信息，一般只会由私有部署的管理员进行管理，不可能开放给普通用户使用。而且，平台代码由平台方进行维护，本地把平台代码拉取下来进行开发，就得关注平台自身代码的更新情况，不然无法保证绝对仿真性。

换个思路，只base拖拽生成的管理台代码进行开发，在我们无极平台上也无法成立。主要因为平台的页面产物是数据配置（布局格式是一种类似jsonSchema的协议），没有代码，更无法在这个基础上进行组件开发。

3. 平台级组件开发模式

既然要搭建一个一模一样的平台进行开发如此困难，我们能不能直接使用远程管理台进行开发呢？无极实现的组件开发流程分为以下几步：

主要原理是，通过打通本地和远程管理台的连接，让开发者不需要理解平台代码，只关注自身组件代码就可以了。做到跟vue组件原生组件开发体验一模一样，并且因为直接复用了真实的宿主环境，达到最大仿真性。

分享一下这套流程的实现思路。

远程管理台分为生产模式和开发模式。CLI工具会收集本地仓库的组件开发列表，提供接口给远程管理台拉取。开发模式下，组件的加载策略是，本地组件优先从localhost加载；远程组件则直接从组件的cdn地址加载。这样就实现了本地自定义组件与线上组件在线上布局中混排。

刚谈到远程管理台加载了本地组件JS，实际上，这个本地组件JS会注入websocket客户端和HMR更新模块的代码，当本地代码发生变更，本地CLI的websocket会与远程管理台通信。HMR模块会请求最新的组件JS，并控制DOM节点的更新（无极参考了开源仓库 webpack-hot-client 的思想进行了改造，大致思路两者基本对齐）。

我们来演示一下最终HMR达到的效果：

这样，可以在多个线上管理台上，实时看到组件修改后的效果。并且跟原生的vue组件开发方式，毫无差异。

3. 组件批量开发

方案灰度使用时，当单个仓库10+个组件同时开发时，启动命令首次构建时，在单进程中暴露出性能问题。于是我们的思路是改单进程的串行为多进行的并行执行，每个组件独立子进程进行构建，达到最小化耗时。并且由主进程进行socket连接的分发，最终只占用了一个端口。此时构建中间件主要由以下几步构成：

1、worker进程池，一个子进程维护一个组件的构建服务

2、master进程，维护组件信息池以及socket server池

3、由master进程，统一对远程管理台页面进行消息通信

我们来看看最终的优化效果：

小结，无极目前的组件开发模式，通过复用真实的管理台，最大程度地降低了组件开发的成本。我们相信只有提高开发效率，才能让组件开发者更好地参与到组件生态的共建中，从中孵化出高质量组件。

组件依赖管理

1. 背景

无极是to B的，涉及到大量组件包含组件的场景，例如列表组件和复杂表单组件（一个复杂表单组件会包含输入框、图片、按钮等）。对于无极平台，组件依赖以及组件的线上版本策略，是很重要的一环。

2. 组件的构建方式 - 锁版本 pk 不锁版本

举一个例子来表述问题吧。假设组件A依赖文本输入框组件。

一般会有两种构建方式：

一种是bundle的打包方式，就是锁版本。也就是说，将输入框组件打包进组件A中。

这个方案最大的优点是组件是自治的，输入框组件的版本维护由组件A自行处理，没有组件升级的风险。缺点是管理台中如果也使用了文本输入框，就会存在两个文本输入框版本，可能会导致样式不一致等问题。并且，会增加组件的JS打包体积（例如，柱形图和饼图，都依赖了echarts组件，把echarts组件各自打包进两个组件中，是不是有点可怕？）。

另一种是类似AMD异步模块加载的方式，也就是动态依赖。假设组件B也依赖了文本输入框，他们内部只会声明自己的依赖链，不会把输入框组件打包进自己的JS中，最后加载的输入框组件JS会指向同一个。这种做法的好处是组件是解耦的，输入框组件可以快速升级，全局只需要维护一个输入框组件即可。当然，全局升级也是有风险的，它有向下兼容以及稳定性的问题。