web前端低代码工具实践：为中小型项目定制化开发轻量的代码自动生成工具，实用易上手

一、适用场景与项目特色

本项目是一套轻量、易用的可定制化前端低代码模块。对前端交互逻辑存在大量重复的页面来说（例如后台管理类系统），可以起到减轻前端开发工作量、节约人力成本的效果。前端开发人员可以在代码自动生成的基础上，使用项目原来的技术栈进行零门槛二次开发，极大提高工作效率。 市场上的商用低代码平台往往接入成本、学习成本较高，不能完全贴合系统的实际需求，也难以做到完全替代人工二次开发。本项目尤其适合中小型企业系统快速接入应用。

功能特色如下：

1. 有独立的配置模块，支持根据业务系统的实际需求决定配置粒度与丰富程度，可繁可简。配置模块有可视化界面，允许所有人进行页面配置，且可以设计多种提升易用性的功能，例如根据java实体类或Dto类代码直接生成字段的基础信息配置。
2. 脚手架可以针对多种技术栈开发不同的模板。不论现有系统使用哪种框架或组件依赖，都可以基于企业现有的系统代码进行定制模板开发，然后在自动生成的页面上无缝进行后续的二次开发，很适合在前端开发人手不足的情况下减少大量重复性开发工作，并能极大减少传统的ctrl c/v开发过程中经常出现的字段遗漏、错误等情况。
3. 如果企业使用jenkins等自动化部署工具，可以通过jenkins执行工具指令，并直接进行部署。

二、使用步骤和效果

1. 在配置模块进行菜单、接口、字段、交互等属性配置。
2. 在前端工程根目录下运行执行命令，则自动生成有完整交互逻辑的、已实现接口对接的前端页面，和人工开发成果没有任何区别。开发人员可以在此基础上进行二次开发。

三、接入方式

1. 直接将该工具内嵌进前端项目工程。适合单个系统使用。方便快速迭代，有更好的针对性和适用性。
2. 打包成外部模块，安装进依赖包使用。适合多个相似系统共用同一套生成工具，方便代码模板同步更新、同时生效，有更好的普适性。

四、工具结构

1. 配置模块（包含前端页面+后端接口+数据存储）

1） 基础配置内容：

可包含页面菜单位置、接口、字段属性、交互逻辑等。配置属性的粒度，直接决定了生成代码与实际需求的贴合程度，决定了二次开发的工作量的大小。例如，每个字段除了基本属性之外，是否还要决定ui的样式与所在位置？不同字段是否存在交互联动逻辑？开发者需要对开发该工具的复杂度进行取舍。在本落地案例中，配置模块的复杂度适中，没有进行ui样式等配置，页面功能有复杂逻辑和特殊需求的，均选择通过后续二次开发实现。

例1： 以一个常见的列表增删改查类型页面为例
下图是目标页面效果：

则对应的菜单位置、接口配置如下：主要以增、删、改、查、导入、导出等接口配置为主。

对应的字段属性配置如下：

字段类型根据系统常用类型，基本上分为以上几种。不同类型的字段可以进行详细属性配置。比如，数字类型的字段可以进行单位、精度的配置；单选多选类型的字段可以根据项目实际情况进行字典翻译配置、日期类型字段可以进行format格式化配置等等。

有一些复杂结构，是嵌套在主要实体类中的子列表。也可以做到更深入一层的子列表字段配置。

此外，在交互与功能层面，可以配置字段是否作为查询条件、新增和修改时是否需要必填等属性。

例2： 其他表单类型页面（非列表查询类）
如下图所示，页面相关配置根据页面实际需要产生了变化。

已经配置过的历史页面，可以通过历史记录进行查询：其中的ident(唯一id字段)非常重要，在页面生成的过程中，我们就是根据唯一id来查询对应的一条配置数据的。

2） 对配置模块的细节设计进行优化：

填写字段信息时，人工手动对字段进行添加和删除较为繁琐，且容易出现复制错误。所以在本配置模块中，有专门设计根据java代码的实体类或Dto类自动生成字段配置信息的功能。

2. 核心脚手架模块

这一部分是整个代码自动生成工具的核心逻辑所在，从原理上来说并不复杂，其核心原理就是把一个文件中的静态部分与动态部分区分开，并通过接口调取我们已经配置好的数据，进行逻辑处理之后，将动态部分进行替换，然后利用脚手架工具将最终页面生成到代码工程中。

脚手架模块基于plop开源工具实现，大体上可以分为template静态模板+actions逻辑处理+prompts指令设置三部分。

例如以下这段组件代码段，红色部分圈出的组件名称、state状态数据、字典请求代码等个性化部分就是通过动态逻辑加工的，其余部分是每个页面都通用的静态内容。

在以下这段路由代码段中，路由权限、路径、名称、组件名称也是需要根据已有的配置数据进行动态处理的。比如在前面的配置模块中，我们选择了是否需要新建一个父级路由菜单，还是建立在已有的父级菜单下，这两种情况下路由代码段最终生成的位置都是不一样的。

prompts指令为用户在运行该工具时，需要在终端中输入的、临时决定的某些行为，而且该行为不方便在配置模块中进行配置：比如要生成的文件放在工程文件中的哪个文件夹下，还是新建一个父级文件夹？要请求的具体配置数据的唯一id是什么？

为了提升工具的易用性，prompts的数量尽可能减少，而且尽可能支持用户通过无脑回车实现默认操作。比如在本项目的实际应用案例中，原本设计的prompts问题包含三个，其中一个是“请输入token”，使用户能成功访问配置请求接口。但是后续改造时，后端项目把这个配置请求接口加到了接口白名单中，任何用户不需要使用token即可访问该接口，这样prompts的数量就减少到了两个。

3. 指令反馈模块

1） 如果代码生成成功，可能同时新增或修改了多个页面，需要明确提示用户哪些文件被更新了、哪些文件被新增了，方便进行后续的代码检查和开发。

2）如果代码生成失败，需要提示用户失败原因。以下两种情况可能造成页面生成失败：

a. 由于本工具中的动态配置是通过接口向后端获取的，在接口请求的过程中可能由于参数传递错误或网络原因而造成接口调用失败，一般情况下把接口的报错信息直接返回即可；

b. plop.js脚手架工具在代码插入和新增时，对现有文件结构有要求。比如如果你在配置模块中，选择了对一个文件进行“修改操作”，但是实际项目中该目标文件不存在，这时plop会产生报错，代码生成过程中断。

五、调用演示

前提条件：已将该工具包作为外部依赖安装，或已直接嵌入本地工程。这两种情况下，在package.json的scripts对象中配置的执行指令有细微差别。

1. 执行scripts中配置的脚本指令，运行工具脚本。
2. 根据设置的prompts进行回答。
   
   

六、代码资源说明（获取方式见文末）

1. 本资源在实际项目中已投入应用且经过效果验证，所服务的前端项目使用的技术栈是react+antd+umi+dva。

2. 资源1：是独立的项目安装包，支持通过node_modules安装使用，在package.json中可配置脚本指令调用；
   
   资源2：内嵌进前端本地工程使用。配置的脚本指令有区别
   
   两个资源代码均只包含核心脚手架部分，不包含独立的配置模块。独立配置模块采用常见开发技术进行设计开发即可，没有特殊性。

3. 参考价值不大的部分：以.hbs为后缀的模板文件中，有大量代码是基于前端项目已封装好的组件进行设计的。这一部分不具有普适性，不需要进行参考。
   

4. 具有主要参考价值的部分：

资源1 ：

• index.js ： 项目入口，调用plopfile.mjs文件
• plopfile.mjs： 执行prompts–>通过api接口请求配置数据–>根据不同的配置分别调用不同的逻辑处理方法–>结果反馈

资源2：没有index.js文件，只有 plopfile.mjs 文件。作用同上。

5. actionsHandler逻辑处理部分：可以参考如何给actions传递参数，如何拼接、生成模板字符串，尤其是代码中有用到style={{}}代码块时，容易和plop模板语法产生冲突，需要特殊注意。

如有需要获取代码资源，或有定制化搭建代码自动生成工具需求的，请戳 Violet_8080