組件庫不願意解決的表單問題
表單風格體系是前端開發頁面時最常見的功能之一，對於一般需求我們使用組件庫自帶的表單控件即可，但如果表單結合了以下兩種情況，表單控件就會開始漸漸變得難用起來
- 深層次的嵌套管理
- 動態表單的性能
之所以會這樣，是因為表單本身是一種在邏輯上高度耦合，但落地時又不得不拆成零零散散的形式使用，每多涵蓋一種復雜的情況都會使得代碼變得更加復雜，代碼量增加，用戶上手難度上升，用戶使用限制變多
既然組件庫缺少了這部分，我們又真的碰到了這種場景時，手寫一套的難度是很高的，因為它太靈活了，不起眼的 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 個）的兩種，高級寫法就是把不同的表單字段分成一個個小文件，然後按照圖中畫圈部分進行指定使用哪個，把它們一層層給給套起來。
作者：usagisah
鏈接：
https://juejin.cn/post/7322733301668102159