图片2

TO B的低代码平台是利用可视化的方式，将组件拖入画布，结合数据源的绑定，生成管理台的工具。

事实上，管理台的模式相对固定，需要大量的同质化，最适合使用低代码。对于画布来说，UI组件库是最关键的。目前，可以提供多个官方公共组件，以满足大多数管理台的需求。

但业务方必须有定制组件的需求。只要定制组件的生产门槛有点高，就会说服用户，甚至不要直接使用整个平台。最理想的模式应该是，整个画布（甚至所有）区域可以直接使用公共组件；其中一些可以填充自定义组件。它不仅可以完全恢复页面需求，还可以减少重复开发（主要是指平台的公共组件、接口呼叫、平台权限等），最大限度地提高使用低代码平台带来的好处。

对于自定义组件，它必须足够灵活。组件开发人员可以选择共享组件，以便在其他团队建立管理平台时直接使用。或者作为其他自定义组件娃娃的原子。此外，组件最好与项目相互独立，以便任何组件都可以支持跨项目的重用。

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

1.组件开发过程。

目标：与本地组件的开发体验对齐，你所看到的就是你所得到的。这意味着在不发布组件后，您可以看到组件在多个远程管理平台上的各种场景的显示效果。当然，开发者不能理解太多的“个性化”概念（如如何引用自定义组件、自定义属性面板等）。

2.组件依赖于管理。

管理台涉及大量包含组件的组件场景，因此将讨论在线版本的组件策略。

平台级组件开发模式。

1.组件的基本组成。

一个完整的组件由组件本身的UI和属性面板组成。调试时，两者需要连接，相应的属性配置效果需要在组件UI上实时看到。

属性面板一般涉及数据源、管理台页面等的绑定，需要与平台功能进行交换。例如，考虑到最传统的组件开发模式：直接开发一个组件，并将其发布到平台上，而不提供宿主环境。

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

2.传统的组件开发模式-高级版。

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

第一步，拉取平台代码；

第二步，偷偷询问平台管理员取账号密码；

第三步，翻来覆去，跑起整个平台代码，终于想起来是为了开发一个小组件。

DB信息作为平台方工具，一般只由私人部署的管理员管理，不能向普通用户开放。此外，平台代码由平台方维护。当地平台代码被拉下来开发时，我们必须注意平台本身代码的更新，否则无法保证绝对模拟。

另一方面，只有base拖动生成的管理台代码进行开发，在我们的无极平台上建立。主要是因为平台的页面产品是数据配置(布局格式是类似jsonschema的协议)，没有代码，更不用说组件开发了。