我打造了一款，平民化的、高性能、高灵活的表单（vue 篇 -- @usaform/element-plus）
该轮子是我对之前的原理篇的实践后的产物，如何打造一款，平民化的、高性能的，类表单体系（原理篇），本文是阐述造轮子的背景
组件库不愿意解决的表单问题
表单风格体系是前端开发页面时最常见的功能之一，对于一般需求我们使用组件库自带的表单控件即可，但如果表单结合了以下两种情况，表单控件就会开始渐渐变得难用起来
- 深层次的嵌套管理
- 动态表单的性能
之所以会这样，是因为表单本身是一种在逻辑上高度耦合，但落地时又不得不拆成零零散散的形式使用，每多涵盖一种复杂的情况都会使得代码变得更加复杂，代码量增加，用户上手难度上升，用户使用限制变多
既然组件库缺少了这部分，我们又真的碰到了这种场景时，手写一套的难度是很高的，因为它太灵活了，不起眼的 bug 将会经常发生，所以我们可以选择已有的方案（npm包）来解决它
竞品对比
目前我所知道的，这方面做的最好的是 formilyjs，人家是当之无愧的王者级别解决方案，可是上手难度也是实实在在存在的
- 概念太多了
- 上手难度很高
- Vue 相关的文档很薄弱
- 大问题没有，小问题不断（不实际用用你根本想不到有多少的那种），这是阿里系产品的通病，可能是赶 kpi 导致的吧
造轮子的缘由
做个竞品出来的过程，我想同为程序员应该都差不多吧
- 发现问题
- 搜索引擎/ai 找解决方案
- 能 cv 尽量 cv，能用现成就不想手写，能懒则懒
- 实在没法了就自己造个（或者唆使别人造个）
我的思考过程也类似，不硬着头皮用 formilyjs 是因为我发现如果深入使用的话，后果可能会难以把控，主要原因如下
- 团队接受度低。可以的话大家都不喜欢学新东西，尤其是只能应付较少场景，学习成本还高的技术。毕竟大多数表单都是静态的，cv 组件库改改数据即可解决
- 深入使用难度高。
formilyjs这个架子太大了，如果要自定义组件和深度使用的话，文档讲的远远不够，需要扒源码学习和排坑。文档呢有好几份，看之前得先看概念理论，然后在结合例子多用才能渐渐上手，为了一个表单这付出的成本略高了（on my gad 我不想学了） - 扩展难度高。除了开箱即用和官网给现成的，还是得扒源码，否者就得靠经验根据例子进行推导和猜
在我研究了表单相关的解决方案后，造了个轮子 @usaform/element-plus，它适用于深层次嵌套和复杂的动态表单场景中，具备以下优点
- 高性能，只更新变更的部分
- 高灵活，尽量使用用户的组件，其本身只是粘合用的框架
- 优雅的互操作性，在表单任意地方都可以在保持高性能的同时，与其他字段进行交互
缺点
- 为了使用灵活，没有开箱即用的组件，具体逻辑全靠组件库填充，以及用户自己决定，就像是
vue开箱即用了很多功能而react就不提供，自己动手丰衣足食 - 数组组件有很多琐碎的注意事项，需要多思考几分钟（主要是写了很多类型，我本地用了 volar 但发现该飘红的地方不一定飘红，体验略差）
- 目前只提供了一款表单需要的基础能力，功能比较单薄
补充
- 库本身体积不大，因为用的
tsc打包所以会导致 npm 显示的体积很大，对于实际项目打包时，没有什么负面影响（要做的事太多，用的人不多我就用 tsc 打包偷懒了）
一些使用 demo 效果图
基本控件
高级控件------数组
实际代码用起来的感觉如下
这是简单的表单写法，其中 element 是指向具体填充组件的 key
组件可以分为能嵌套的（2 个）和不能嵌套（1 个）的两种，高级写法就是把不同的表单字段分成一个个小文件，然后按照图中画圈部分进行指定使用哪个，把它们一层层给给套起来。
详细文档可以看 npm，更多 demo 可以查看仓库中的例子 github
后续规划
目前可以认为是一个尝鲜版，感兴趣可以用用，为我提提意见
后续会 j进一步优化用户的使用体验，添加更多遍历的功能，添加完善的测试，再做一个 React 版本。目标是做一个易于上手的表单解决方案，功能不在于多丰富，但一定会尽量保稳定可靠
文档我尽力写了，如果有不太懂的喊我我在改，如果用的人多我会计划单独做一个像 element-plus 那样的文档站点
如果有 bug 可以通过私信或者提 issue，有好的想法和意见都可以告诉我。我希望我造的是一个有意义的、稳定的、能真正解决问题的轮子，而不是一个显摆技术的玩具