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...
如果有什么建议，欢迎留言～