【原创+开源】五分钟一个后台页，AI加持下的低代码设计思路

AI根据PRD截图标注生成示例

配套工具 ：Fundamjs

Gif 图有点大，加载中** ... 稍等 ... **

低代码的一些实现思路演进

0. 非AI - Json Scheme生成

UI搭建

编写一个可以进行任意层级搭建的搭建器，然后通过拖拽、设置组件属性等操作，最终可以生成一套形如Json Schema的Json

搭建器基本布局

表格列配置

本篇非主要讲解搭建器实现思路，只简单说明几个注意点：

UI搭建的拖拽实现，最简单的形式可以是仅做竖向位置拼接，并且不支持多层子项嵌套。这样也能满足一些极简的场景，但最对于一些非极简的场景，比如弹窗的表单里面需要用不同标题进行分组，这时需要将Title套入Modal下面的Form里面，有时甚至更深的层级。做多层实现时提前规划好不同UI组件的不同类型，比如是容器组件（例：卡片）还是非容器组件（例：按钮），以及容器组件的可容类型，比如：Card右上角（extra）是不允许放Table等组件的
很多组件的属性配置是有很多共性的，比如各个表单项的必填、label宽度等，以及共性容器型组件配置：Table展开行、Modal的内容、Card的内容，可以提前规划好
对于常用的组件组合可以做成一些组件模版，例如：筛选卡组件模版，包含卡片、Form容器、一个示例FormItem、一个按钮组重置+查询
对于常用的页面组件组合可以做成一些页面模版，例如：筛选卡+列表卡+示例按钮+弹窗做成一个非常常见的增删改查页面模版，可以提前把关联关系都配上。

联动配置

主动触发

联动配置有诸多形式，最常见的莫过于主动触发。即当点击某个按钮打开某个弹窗时，直接为按钮配置一个动作。

例如这里为筛选表单的重置按钮配置了两个动作：重置整个表单、刷新列表

被动触发

这是函数式编程中最常见的思路之一。试想一下一个列表页查询、重置、新增、删除、弹窗编辑后都需要重新更新列表数据，但在配置时肯定不能很"死"的把这个页面所有表格都做成有操作就刷新，因为还可能存在一些父表格展开的子表格，也可能还有弹窗表格。按前面主动触发的思路就是为每个按钮都新增一个"某列表数据刷新"的动作，这样显然也很麻烦。这里可以利用一个系统层面的隐藏字段或者一个系统层面的query字段。根据抽象动作封装（见后文）的动作类型进行是否需要页面数据刷新的判断，对于需要的场景直接无脑更新系统字段（比如最后更新时间）即可，此时只需Table配置一下打开一个监听系统字段更新的开关即可

动作封装

要想在搭建器进行0代码的搭建，对各种动作的封装缺一不可。在现代web应用的开发中，各种功能层出不穷，看似很多，实在可以轻松的封装出大多数动作。例如：

地址栏参数更新
远程数据获取并回显
远程数据提交
弹窗
二次确认弹窗
二次确认气泡
表单清空
表单重置
表格选中行清空
... ...

这里不一一列举，总之封装所有常见Action之后，同样类似组件属性配置一样，找出它们的共性和不同点，然后就可以0代码为UI组件配置各种动作了

🔔 这些思路不光适应于后台搭建，对于toC的网页、小程序，甚至APP一样适用

数据池 - 被动触发优化与联动处理

想象一下表单radio选A时出现另一个Input、选B时隐藏，在搭建器里面如何配置呢？可能你会想到类似于金山表单的那种主动式的处理方式。那如果radio选中A发送一个远程请求，远程请求返回true再展示呢？

为了应对各种复杂的联动场景，我会把各个组件的所有状态&数据、接口的状态&数据、Query的数据、history的数据、Table点击行的数据等等进行全局统一的管理，并分别抽象成各个reactive对象，包含它们的组件props属性，状态属性、实时填写的值等等。这样做被动触发时更加简单，只需要关联数据池中相关组件的属性即可

别名

要想在搭建器选择联动组件、数据池数据依赖时更加的直观，可以为每个组件、请求对象等都加上一个别名配置，否则将展示一个可读性较差的唯一ID

示例Schema

此时，已可以通过数据池进行任意的联动，这里给出一个组件schema示例片段

json 复制代码

{
  "GnarButton_fYfcaz": {
    // 全局唯一ID，数据池中的Field对象名
    "$id": "GnarButton_fYfcaz",
    // 别名，搭建器配置联动时，直接选择此别名
    "$alias": "筛选表单重置按钮",
    // 权限管控
    "$auth": false,
    // 使用的组件
    "$component": "GnarButton",
    "$slot": {},
    // props配置
    "$componentProps": {
      "title": "重置",
      "block": false,
      "danger": false,
      "disabled": false,
      "ghost": false,
      "type": "default"
    },
    // 触发器 - 这里串行触发两个动作
    "$triggers": [
      {
        // 所有动作共有的属性
        // 触发方式
        "condition": "onClick",
        // 动作类型
        "action": "FORM_RESET",
        // 监听数据池中的数据，这里没有监听，监听值改变时，也可以触发
        "observe": [],
        // 执行规则，数据池中的数据或者js表达式。结果为false时不会执行本次动作
        "rule": "",
        
        "external": {
          // FORM_RESET特有的属性，指明重置的那些表单，可以一次性重置多个表单
          "components": [
            "GnarForm_XhzQBB"
          ]
        }
      },
      {
        "condition": "onClick",
        // 更新地址栏query
        "action": "QUERY_SUBMIT",
        "observe": [],
        "rule": "",
        "external": {
          // 更新的参数 - 来源于数据池
          "params": [
            {
              // 有key时，包裹valuePath取到的值为一个对象
              "key": "",
              // 数据池取值
              "valuePath": "GnarForm_XhzQBB.form.values"
            }
          ],
          // 输入/输出参数转换，可以通过pipe为远程请求、query更新等场景添加一些额外的参数，以及改写一些远程返回的参数
          "pipe": {
            "params": {
              // 重置后回第一页
              "pageNum": 1
            }
          }
        }

      }
    ]

  }

}

数据池依赖配置展示

上面配置看似相当麻烦，实则就是搭建器下拉选择几下

1. 非AI - JS/TSX代码生成

说明

做过schema生成页面/组件的同学，或者直接从上面Json Schema生成可以知道：一个不太复杂的增删改查页面生成的schema可能相对代码来讲是成倍增长的。做到这里就会产生一些问题：

搭建平台到底是要做搭建组件、页面、项目的全生命周期（首次搭建、后期迭代、重构升级等）的管理，还是仅做个首次一次性生成json、代码的工作？如果有些需求搭建现有功能不满足怎么办？

（🔔tips：如果要做全生命周期管理的搭建器，前期一定要规划好不满足场景的支持，比如设计Scope对象，可以传入用户手写的组件、方法等，搭建器显示一个占位即可）

生成的Json Schema可读性极差，概念太多，新用户上手困难，若非强制推广，可能导致：认真读文档的同学理解了所有概念却能提高效率，而对于本身就对新技术/事物带有排斥性的一些同学可能直接不想打开搭建器，直接看着schema手撸新代码的话比较困难

生成jsx/tsx代码

针对说明中的问题2，为了更易理解和上手，我又设计了action的模版代码抽象，并且做了一套可以对生成代码进行回显配置表单的功能，当然这其实也没什么高级的，就是一些AST解析工作。搭建器到此即可进行三种不同形式的配置：UI配置、数据&联动表单配置、代码编写

实现一个重置按钮两个action的生成代码

此时在联动与数据配置栏，进行【重置】按钮的两个action配置后，不再是生成json，而是根据action模版直接生成一段多个action组合的js代码，这段js代码只要��按备注修改也还可以回显回配置表单里

2. AI - Fundam搭建

随着如今AI技术的不断发展，反观目前业界大部分各种低代码/0代码搭建器与直接通过数据表/数据模型/领域模型/前端模版/前端模型等形式生成已经不够"智能"，并且这些技术的产出物通常为一个可读性不高的json schema、js+schema混合代码、以及可读性不高的jsx/tsx代码，类似上面介绍的两种，可能导致"搭建一时爽，维护火葬场"的囧境

Fundam的诞生即是在现今AI的加持下，做到直接生成上手简单、可读性高、代码简单、便于维护的jsx/tsx代码

示例

AI

传统搭建器

这里AI根据一个Prd标注了一下筛选字段，以及一个远程请求的字段、列表请求等，直接一分钟即生成了一个实现40%功能的页面。因录制大小限制，实际还可以继续与之对话进行代码调整，弹窗代码添加等等

说明：Fundam的核心实现思路即是用最简化的代码生成各种功能，可能部分设计在技术大佬们面前看来有点"异类"，不遵循代码模块化管理，比如请求相关的管理等等。

在我目前看来，对于同样一个组件 / 页面的实现， **AI学习的代码量越大，成本越大，导致错误的概率越高，生成结果的差异越大。所以基于这个思路，目前仅用了三份training data** **（总500行左右的描述和代码）即实现目前第一版的** FundamGPT

可以通过设计稿图、PRD图、其它截图、文字描述等生成代码，更多示例请参考 Fundam

写在最后

AI / Fundam 不是万能的，若生成的代码非你想要的，可以继续与之对话进行调整，目前FundamGPT的训练数据还太少，Fundam组件也还不是特别丰富，欢迎大佬一起共建，后面用的越多，数据越多。会更加强大.

觉得还不错的话，欢迎关注 github.com/cdrslab/fun...

如果有什么建议，欢迎留言～