导读
低代码无疑是近几年比较火的主题，笔者之前有过一段低代码开发的经历，还是有一定的心得体会。最近有一些契机，想把之前的经验整理出来，方便自己构建一个完整的体系。由于并不是先有体系后有文章，所以该系列只能算是“漫谈”，更多的是想到哪写到哪。笔者也会尽量控制篇幅，让每一篇文章都能够独立存在，每篇之间又能拼起来形成一个整体。
另外，职业道德素养问题，不方便透露太多细节的东西，所以更多还是以理论为主，提供一个战略选型方向，还请大家见谅。
正文
前端三大框架带来的改变
笔者在《用函数式编程写出“傻瓜”都能看懂的代码》中提出了一个观点：
另外，从目前流行的三大框架来看，都已经逐渐“数据化”。以 React 为例，其抽象思想可以简化为
UI = fn(state)，利用 VDOM、diff、JSX 等方式将 DOM 操作过程屏蔽，实现了 state（纯数据）与 UI 的映射，其带来的影响就不展开了，这里只强调一点：目前前端开发的绝大部分工作是在处理数据（state） ，而不是像之前 Jquery 那样直接处理 DOM。
MVC 也好，MVVM 也罢，其实都意味着现在的前端框架已经完美的将视图（View）、逻辑（Controler）、state（Model）解耦了。我们在写代码的时候，只需要把组件的某个属性与 state 的某个值绑定，就不再需要关心任何视图层面的事情了。剩下的就是如何对 state 进行操作，也就是 UI = fn(state) 中的 fn。很明显的，其本质就是一个函数，而且是个纯函数。
说到这，给大家介绍一个库，google 的 blockly，可以在网页上通过拖拽，像搭积木一样组装出一个可执行的函数。没错，就是现在少儿编程培训的那一套东西，笔者甚至猜测许多少儿编程的底层实际用的就是 blockly。
说回重点，在 blockly 的首页，我们可以看到，通过拖拽，右侧是可以直接生成 JS 代码的，再重复一遍，是可以通过拖拽直接生成 JS 函数代码的。这意味着我们已经把前端低代码的问题解决了三分之一，突然这么说可能有点突兀，没关系，笔者稍微展开讲一下。
低代码的流派
笔者了解的低代码流派主要有两个，一个叫表单驱动。第一步就是拖拽生成一个【表单】，根据表单的字段结构就有了【数据结构】或叫数据模型，同时也就有了数据的 CRUD，再加入表格、图表等组件来承载数据，让数据的展示更多元化。由于篇幅有限，就不展开分析了，大家大概知道这种实现的思路即可。
另一种叫模型驱动。与表单驱动不同的是，第一步先新建个【数据模型】，可以简单的类比为新建一个数据库的表，同时就有了该数据的 CRUD。然后这个数据是被绑定到表单、表格、图表，还是作为某个不可见的定时任务的输入都可以。
可以大致体会到，表单驱动更符合普通非开发人员的思路，模型驱动比较符合开发人员的思路。作为码农，笔者当然对于后者更为熟悉。而模型驱动的实现，又可分为两种类型。
一种是在 APP 执行时，页面、数据模型等都是实时解析渲染的，也就是需要自己开发出一个【运行时解析引擎】，用来将拖拽生成的 APP 模型数据实时解析出来。笔者将此称之为解析型。
另一种是拖拽生成 APP 模型数据之后，直接将其编译成前端代码，最终的生成物就是 JS、CSS、HTML，与我们平时写代码的生成物一模一样。笔者将此称之为编译型。
当然，表单驱动也是可以用这两种类型实现的，只不过一般都会采用类似解析型的实现方式。绕了这么远，介绍了这么多概念，终于可以说回主题了。
笔者选择【模型驱动 - 编译型】的思路来探讨低代码的实现，主要原因是，如果生成了代码，那么理论上可以极大地借力于现有的开发生态。举个最直接的例子，如果我们能够生成 React 或 Vue 的源码，那么就可以借助 Taro 或 Uni-App 等现成的库来实现跨平台的目标。而且也更方便的集成自定义代码。
说了这么多，总结成一句话：笔者就是想通过可视化托拽的方式，生成与我们平时开发一模一样的代码。且为了更聚焦，本文只重点讨论前端低代码。
数据模型可视化生成
上文已经分析到，要实现前端低代码需要实现视图、数据、逻辑三者的可视化拖拽。目前理论上用 blockly 已经可以实现逻辑的 JS 函数代码生成。下面来看下另外两个。
用过 yapi 或类似 mock 工具的同学一定对 JSONSchema 不陌生，它是一种用来描述和校验 JSON 的数据，官方定义如下：
JSON Schema is a vocabulary that allows you to annotate and validate JSON documents.
举个例子就明白了，很直观：
JSON Schema
{
"$id": "https://example.com/person.schema.json",
"$schema": "https://json-schema.org/draft/2020-12/schema",
"title": "Person",
"type": "object",
"properties": {
"firstName": {
"type": "string",
"description": "The person's first name."
},
"lastName": {
"type": "string",
"description": "The person's last name."
},
"age": {
"description": "Age in years which must be equal to or greater than zero.",
"type": "integer",
"minimum": 0
}
}
}
Data
{
"firstName": "John",
"lastName": "Doe",
"age": 21
}
所以理论上用 JSON Schema 来描述前端数据是比较合适的。另外如下图， Yapi 实际上已经实现了可视化生成 JSON Schema 的功能，所以数据这块我们也基本已经解决了。
值得一提的是，毕竟 JS 的数据类型较其他后端语言要少，所以是不能直接映射给其他语言去用的。不过这也不是太难的问题，仿照 JSON Schema 的思路扩展数据类型即可。
另外，采用 ER 图的思路来构建数据模型也是一个很不错的选择，毕竟是软件开发领域的老兵了。
视图可视化生成
这块是最大头，主要难点有大概如下几条：
- 技术上如何实现拖拽，以及整体的交互；
- 如何实现与数据模型、逻辑控制器的绑定；
- 理论上组件是无穷的，如何制定一个格式规范，让组件像插件一样解耦开发和集成；
- 如何生成源代码。 由于篇幅关系，打算另起一文来写，后面会补上链接，请各位海涵。
（2021.12.19 更新：【低代码漫谈】拖拽生成视图的要点）
结语
笔者对与 APP 的抽象为：APP = UI（界面） + Data（业务数据） + Logic Control（逻辑控制）。另外，Access（权限）作为特殊的一种数据，可以被单独拿出来，因为它跟上述的三部分都有关系。这个思想实际上与 MVC、MVVM 等模型抽象大同小异。从前后端分离的角度来说，前后端都有自己的 MVC 模型。对于后端，整个前端都属于 MVC 中的 V；而对于前端，整个后端只是 MVC 中的 M。理解这种抽象关系是很关键的，是关键中的关键，笔者暂时想不出合适的类比来形象的描述这种关系，所以只能强调此处的重要性，然后让各位同学自己理解了。
后续打算补上前端低代码视图部分，完成前端低代码，然后就是后端低代码，最后可能会再补一些权限、发布、编译之类的边边角角，各位敬请期待。
“读书使人充实，讨论使人机敏，写作使人严谨”——Francis Bacon
