前端工具组件到微代码平台的思考

前言

对于一个简单的列表页面，我们看到只有一个标题，一个表单（表单），一个表格（表格），而要实现他我们至少要做以下几件事

画出界面，包括列表以及列表对应的弹框按钮
根据后端接口绑定table和form的数据，并测试好相关交互
根据后端端口，绑定列表弹框字段

一般的前端到了这里也就是一个阶段性的结束，列表页面也基本上能够完成一个基本的用户交互，但使用大厂的测试用例一跑就会出现这样一些错误：

检索条件容错差，输入条件空格开头和结尾，检索不到对应的项目，可输入几万字的数据，并且检索后直接导致服务器奔溃
检索条件未点击检索，条件就开始生效
页面增改操作后，页面没有重新获取数据，或直接刷新到第一页
最后一页如果只剩最后一条数据，删除后明明有数据确显示无数据，页码为最后一页
离开页面查看详情后回到页面，检索条件全部丢失

把上面所有的流程细节都修复过后，我们会不禁发现一个简单的页面，尽然会花一个前端接近1天甚至超出一天的工作。而且更可怕的是这个前端，一般都不会归纳这些交互设计，更不会跟他和他的团队累计下这些交互设计，然后同样的问题，这个人，这个团队，在不久的将来又会在犯一次。

问题展开

我们从上面的工作可以看到当前前端工作主要由界面代码化，前段交互设计与实现，后端数据绑定三个部分组成。这个三个方面分别面对这样一些问题

界面代码化面临：

没有真实可用的设计图，设计图没有考虑到实际界面的大小，以及电脑屏幕的响应变化
重复的布局，不同的前端做，即使是一个系统产出两份代码不同，质量不等的结果

交互设计与实现面临：

设计结果，团队及个人都没有积累，同样的错误，反复促发
产品交互设计，由不同的前端来设计容易导致不同的体验，
以上两点都满足的情况下，庞大的工作量，既累又容易导致未知细节设计的丢失
不同的人做同样的设计，浪费工作，单人设计其他人抄写，又因为代码水平等各种原因难以实现

后端数据绑定：

后端团队接口文档，先实现后输出，导致前后端无法分离开发，整个开发模式陷入开发先行的陷阱
产品，后端，前端同样的工作高度重复，费事费力,且越处于开发下游，开发越困难。

除了以上问题之外，中小型公司还面临着后知后觉带来危害，即公司单位效率低于大公司3倍以上，大公司在用可视化和微代码平台开发的同时，我们还在为了业务和修复业务而代码。

前端UI框架及业务封装系统的建立

前端问题的产生非一朝一夕，问题解决也可以用渐进增强的方式逐步解决，要解决以上问题首当其中应该解决重复的功能业务封装。功能业务为什么会重复，一是封装难度大，二是没有适合的载体。如果我们要将列表页面封装成一个组件，要兼容各种检索条件，各种单行数据处理，基本是不可能的事情。既然我们会因为一些整体中局部的不同，导致整体不好封装，那我们是不是可以先封装局部，将局部的功能抽离成组件，通过降低局部的难度，来轻松的完成整体面向对象的父类封装。基于这个思路，我们可以搭建一个以局部功能封装为目标的ui组件库，和已累计业务父类对象的为目标的示例项目，不同前端通过继承父类实现页面编写，达到解决重复的目的

如何搭建一个高效可服用且面向对象的ui组件？我的思路是建立json化的组件库，通过暴露字段，钩子函数及普通函数，让组件自身完成对应的业务逻辑，交互细节，html和css渲染，不同的样式仅通过css class复写来完成（html不用考虑，最小单元的功能，html的机构基本固定）。然后，父类组件通过给json化的局部组件提供配置和基础字段，完成局部细节功能，通过对字段获取方法的维护抽离，达到父类组件的封装。同时因为业务功能都集中在父类中，开发仅负责组件的基本配置，可以轻松的将功能复用，进而达到业务封装的目的

ui辅助工具

其次封装完成了，就要考虑如何进行推广，如何低代码的掌握。所以我们在组件功能封装完成后，首要考虑的就是文档系统建立的和ui辅助工具编写。文档网上有很多现成的，所有ui架构都有成熟的文档翻译工具参照。

辅助工具就可以稍微自我发挥一些，我觉的辅助工具可以偏向快捷键，可视化的方向。

针对快捷键功能为主，我会想到这样一个问题，同样的功能单元，程序员都会都想用一些同样或者相识的名字（如表单，表格，按钮）来让别人快速明白它们是啥，而对这些好的单元，好的命名经常就是我们所说的命名代码规范，然后我们是不是可以用这些规范的命名来作为快捷键，让用户通过记住快捷键来代码的快速开发和团队规范的推进。

然后json化的组件可以作为可视化开发或者低代码平台的基础，通过拖拽完成一个json，或通过配置一个json完成一个页面，都比直接实现他们（拖拽实现一个页面，和直接书写一个页面）简单的多。

前后端交互工具搭建的必要

解决了封装的问题，强大了自身，就不得不面对团队问题的优化。其实当前大成都前端开发环境十分糟糕，大部分的团队根本没有实现前后端分离。大部分人都知道，前后端分离，那是什么导致他们耦合在一起的，最开始，前ajax时代，大部分通过服务器渲染，通过服务器语言，直接绑定数据，前后端经常是一个人在做，后来有了ajax，有了juqery，数据绑定逐步靠向前端，但绑定比较困难，juqery多负责页面效果；在后来mvvm出世，数据绑定前段难度降低，页面交互逻辑大规模转移到前端，前后端正式开始分离，但是这依然不够，因为分离后前端是基于接口数据进行前端交互及显示，接口不能预先设计，那就是开发先行，前端依然对后端有依赖，并且一直处于后段开发完成下游，无法并行开发，进而导致一系列问题，如：前端沦为后端的测试；后端接口千变万化，前端功能重构成灾。就算实现了以swagger为代表的接口文档，前端依然面临没有接口数据支持交互细节验证，文档中不能快速找到接口。而且前端封装到了最后，字段配置大多都源于接口，交互大多都基于接口字段结构，交互细节基于结构封装后，配置字段大多可以根据后端接口文档生成。