目前市场上有多种低代码前端框架在竞争，其中的佼佼者是amis。这个是百度前端开发团队设计开发的框架，非常适合后端管理平台类应用，使用amis，此类工程开发速度能提升10+倍，大幅度节约时间和开发成本。
它的网址：https://github.com/baidu/amis
文档：https://aisuda.bce.baidu.com/amis/zh-CN/docs/index
文档在开头就有对它的介绍，这里就不重复了。我只说下自己对这类框架技术的理解和一些经验体会。
这套框架是基于 React 前端框架，做的二次设计开发。你可以把它看成使用了“数据驱动”技术的UI框架。所谓“数据驱动”，就是可以使用数据描述来改变系统的运行行为，而无需修改系统本身。相当于配置不同，系统就不同。
比如，你的系统可以支持从配置文件中构建并调整自己的运行逻辑，发现要展示组件A，隐藏组件B，并执行功能C，这个就是数据驱动。
数据驱动类似于“领域特定语言-DSL”，这个优点实在是太多了，在它支持的定义范围内，使用起来真的是太方便了。
为什么 amis 是基于 React 开发的呢？我猜想可能的原因是 React 的设计适合做这个，React 的组件很容易抽象成组件描述文本，只要把这个描述文本定义清楚，就可以做数据驱动，生成 React 组件。
做过 React 开发的人都会有所体会，React 应用开发太麻烦了，特别是交互操作比较复杂的情况下，要编写的处理功能很多。但是使用 amis 会大大缓解这点，消除疲惫感。因为默认的设定在绝大多数情况下都是够用的，特别是后端管理类应用。
我曾经使用 amis 开发过一套后端管理平台，察觉到它的优点。后来又把它塞进了 Electron 客户端，没问题能运行。但是这次我察觉到它的不足。
对于框架类应用而言，尽可能的提供灵活性是很重要的。早期的 amis 版本，灵活性比较欠缺。某些任务的实现相当的困难，但是1.7版本之后，支持事件，相当程度上改善了这个问题。不过，使用 amis 系统，调试会增加一些困难。因为数据描述的组件实际是要编译后创建并执行的。
如果灵活度欠缺，会导致某些问题出现。比如，刚开始实现的功能，仅仅因为后面的需求变化了一点点，可能就导致前面的实现全废弃了，因为这条实现路径无法实现新的需求，只能重来。它的一个主要问题在于：没有定义好的办法，实现与其它组件的互相操作。这种互相操作的不足，是目前使用它面临的主要障碍。目前 amis 系统还匮乏一些 hooks 的支持，导致一些操作实现路径显得复杂机械。如果后续版本有这样的支持，那就会更加灵活方便了。
这些 hooks 如果可以提供，在组件的重要操作节点上就可以进行判断、拦截、修改，会大幅提升系统的灵活性。此外，应该对常见任务，考虑一个合理、完善的实现路径和案例，这样大家就不必反复研究怎么样才能做到。
另外，我发现使用 js 格式，而不是 JSON 格式描述数据，更为灵活方便。JSON 格式描述的优点是很容易判断格式是否正确，但是如果要插入某些 js 代码，就不如 js 格式便利了。JSON 格式描述，显得操作逻辑有些“生硬”，交互一复杂，就会出现不少的问题。
具体的解决模式，有几个套路。
使用 LocalStorage 来缓存数据。这个经常可以解决数据传递的问题。此外，amis 暴露出的一些操作接口，可以写成 js 的函数，而这些函数大部分是可以操作所在页面的 formStore的，这样的处理虽然有些 hack，但是可以解决问题。
使用 fetcher 接口拦截 API 调用。这个估计是很多人没想到的。这个接口是使用 amis 必须实现的功能。你可以使用 axios 这类模块实现，官网也有案例程序。使用 axios，可以非常方便的拦截 amis 组件发出的API调用，实现常规办法很难解决的需求。
比如，传统的服务器端接口已经形成，无法跟 amis 框架的要求匹配，不能修改怎么办？
解决的办法，就是使用 fetcher，拦截里面的请求，把对服务器的交互操作修改掉，互相做个适配就可以了。这里使用 js 的 Promise 功能，是很简单的。
最后，还是强调优先在后端管理平台上使用 amis，因为这类平台功能比较模式化，有特殊要求的是少数，大部分功能都是 CRUD，amis 实现起来非常的快捷。如果是客户端、面向用户类的应用，复杂多变的逻辑，还是会让人头痛一阵子的。
如果要求更简单，那使用基于 amis 设计的爱速搭，拖放操作就能设定系统，更为简便。
取其长，充分发挥它的优势就可以了。
一个可以供参考的 amis 起步项目：amis react starter
https://github.com/aisuda/amis-react-starter
建立了一个amis前端开发群，可以交流前端开发的各种问题，有兴趣可以加入。群号：188262601
