前言

工作中又遇到了低代码的研发工作，所以借着机会跟大家分享下我的所思所考，大多数公司都是后期为了应对重复的中后台项目或者H5等页面，为了更好的降本增效，那么低代码似乎成为了自研公司的前端团队的一把杀手锏。

面向json的Amis低代码

前段时间搞了个低代码的封装工具lowcode-engine-editor, 这个低代码编辑器本身是基于amis-eidtor封装的，通过不完善但也能落地的amis-eidtor封装后也成功快速落地到企业中后台的生产环境中，iframe来加载不同模块，并成功上线了5个多页面。

基于amis-editor的低代码编辑器的封装

优缺点

优点:

1. 首先值得肯定是社区生态、文档是很好的，包括上手程度其实并不难

缺点：

1. lowcode-editor只是暂时不开源文档补全，带来了未知的风险。在处理中也要大量翻阅源码做实践。
2. 功能生态并不面向未来，你可以看到并没有出码、生产低代码组件等
3. 并没有协议约束，术语约束，带来的沟通成本可能会更高

amis核心原理

amis官网其实也描述的很简单，amis 的渲染过程是将 json 转成对应的 React 组件。先通过 json 的 type 找到对应的 Component，然后把其他属性作为 props 传递过去完成渲染。

下面我画了张图简单描绘下amis原理

大致就是每个json会有一个渲染器包做渲染，核心区域在画布上，用iframe来隔离环境，同时操作区做编排等操作，本质就是操作json来实现跨平台，只有有一个渲染器就可以将json解析渲染到视图。是不是可以手撸一个简单的低代码框架了呢？下面是我花了两天搞得简易框架，有些许简陋，但足以看出低代码其实并没有那么难。

ccj-007/easy-lowcode: easy-lowcode快速学会低代码框架原理 (github.com)

面向企业级搭建平台的Lowcode-engine

低代码引擎是一款为低代码平台开发者提供的，具备强大定制扩展能力的低代码设计器研发框架。

优缺点

优点：

1. 定义了搭建协议、物料协议、资产包的协议，术语，落地了多个低代码平台的统一管理规范！
2. 渲染有运行时和ProCode的预编译，运行时通过渲染器动态渲染，ProCode纯代码的出码规范生成不同框架的源码，并构建成boundlejs渲染到视图。是不是比amis强？
3. lowcode-engine的可以生产自己的低代码组件，是不是更香了，其他的插件化带来的拓展性。
4. lowcode-engine在生产低代码平台，是不是可以做出H5、中后台、小程序等不同的低代码平台呢？而amis在生产项目
5. .......

缺点:

1. 明显协议的上手难度就比amis高了很多，包括大量的api

lowcode-engine核心原理

下面摘抄了lowcode-engine官网的一部分原理的实现图，简单说明下足矣，其实核心原理也像amis那么简单。

协议就是一个可以完整描述一个东西的对象，一般都会有编辑器、物料、页面等的描述对象，这些规范的json需要低代码引擎解析生成，然后与编辑器通信，最后渲染在视图，这个过程会有生态的植入，比如通信的一些包，插件等。最后生成不同的低代码平台

看着花哨，其实就是抽象解析出一个对象、然后操作移动对象里面的节点，然后通过一个编译器生产源码，然后生成渲染。

万物可插件化，扩展性杠杠的，虽然还没实践lowcode-engine，但是足够让人期待。

如何生成源码

先定义项目结构，会存在很多插槽来存放模块，模块由文件生成，文件内部是一个个代码块，全部抽象成一个复杂的描述对象，当然这里面一定有一个映射关系，这个就是一个不同框架编译器做转换，然后根据你的项目环境，通过这个编译器生成对应的框架的源码。当然会有前置优化，做校验和检查以及修复，也会有后置优化，如prettier的代码格式化。

总结

amis是偏向中后台业务的搭建项目的低代码框架，而lowcode-engine更希望做行业的标准化，构建多个平台，并统一规范。所以看起来好像lowcode-engine更适合做这把低代码的杀手锏。

文章中有缺陷在所难免，也希望能得到大家的指正，觉得不错可以点赞关注收藏