中后台表格自动生成工具
# 开篇提示
这是一篇低代码实践文章，根据平时业务抽象出来的一个自动化后台表格页面生成工具。工具的代码构成并没有用到特别高深的技术点，都是平时常用的IO读写操作。
既然是自动化生成表格页面，那么是通过什么方式达到的自动化呢？首先说明一下，“自动化”这个词，别想象成是一个AI控制的，无需人类动手的工具。“自动化”的体现是：用户只需要点击一个按钮，那么工具会自动写入相关业务表格代码逻辑到项目中。
而表格业务逻辑这一块，既然都是业务逻辑了，那么相关业务代码的组成就不会一成不变。所以，我们应该如何根据产品提供的原型、服务端提供的接口文档这两块信息来生成相关业务逻辑代码呢？
# 业务表格中，谁是常量？谁是变量？
这是很重要的一个问题，只有把这个问题想清楚。那么，剩下的只是对想法的实现。
在一个中后台项目中，该项目的构成可以说是70%的表格页面 + 20%的各种表单弹窗 + 10%的其他页面或功能。而这70%的表格页面，通常的组成方式是什么？通常会有搜索区域 + 表格区域 + 分页区域。
在这三块区域内，我们会把分页功能封装到表格组件中，对外提供分页props即可，那么生下来的还有什么？还有搜索区域 + 表格区域。
那么，在前端生态中，阿里的antd团队提供的ProTable组件，把搜索区域的相关交互组件以配置的方式进一步的封装到表格组件中。可以说ProTable组件极大的提高了前端开发人员在处理中后台表格页面开发效率，ProTableyyds！
通过ProTable组件把整个表格页面的的搜索、分页都会以相关配置来进行管理。到这一步，我认为已经到了业务代码封装的极限了。因为你不可能把一个表格页面复用到多个页面业务逻辑中吧？如果你这样做了，那么写出来的代码真的有维护性吗?
所以，当我们需要写一个新的页面的时候，是需要新建目录、配置页面路由、写入相关业务信息到表格中，然后进入提测流程。
那么这个流程纵观下来，什么在变？什么又是一直没有变？
# 常量
上述流程中，没有变化的一直都是表格。再具体一点，没有变化的是表格的各种功能、交互；分页的交互功能；搜索区域的搜索功能、输入组件；
这些是一个表格页面通常不会变化的容，所以工具的处理是封装这些不变的内容。让变化的内容由接口文档来维护，因为业务的改变，其接口文档是需要修改的。所以这里把相关变化的内容统一到接口文档这一块来维护。
# 变量
不变的是表格页面的各种常用功能，而变化的是业务，业务变化的具体现则是表格上每一列的名称、搜索区域具体的交互组件 。而这些变化的信息，也是在影响每一个业务表格表格页面的，这也是每一个业务表格页面的需要写的业务逻辑。那么我们可以根据这些变化的信息来自动生成业务表格页面的业务逻辑吗？如果知道变化的信息，那么必能生成相关业务逻辑。
如何来告知工具变化的信息？以及变化的信息的维护？