1. 雙層架構(gòu)是被需求逼出來的不是設(shè)計(jì)出來的AutoForm 這個(gè)名字最早只是我們內(nèi)部團(tuán)隊(duì)一個(gè)工具倉庫的代號(hào)后來用的人越來越多才慢慢變成了一套可以獨(dú)立維護(hù)的輕量級(jí)雙層架構(gòu)。所謂輕量級(jí)不是指代碼少到只有幾百行而是它不給使用者預(yù)設(shè)一堆必須接受的框架所謂雙層就是我把表單開發(fā)里的幾乎所有問題收攏到兩個(gè)層面Schema 定義層和 Renderer 執(zhí)行層。這篇文章不打算把架構(gòu)吹得多漂亮重點(diǎn)講清楚這兩層各自解決什么問題、中間那條契約長什么樣以及我在真實(shí)項(xiàng)目里踩過的坑。如果你正在維護(hù)后臺(tái)管理系統(tǒng)、做低代碼平臺(tái)或者在糾結(jié)到底該不該選一個(gè)表單引擎這篇內(nèi)容應(yīng)該能給你一個(gè)比較務(wù)實(shí)的參考。1.1 我踩過的兩條老路先說最常見的做法每個(gè)表單頁面單獨(dú)寫 JSX字段、校驗(yàn)、聯(lián)動(dòng)邏輯全部堆在組件里。這種方式的優(yōu)點(diǎn)是直接、沒有魔法缺點(diǎn)是表單一多就失控。一個(gè)五十多個(gè)表單的后臺(tái)系統(tǒng)字段改動(dòng)是高頻需求比如某個(gè)下拉框的選項(xiàng)變了、兩個(gè)字段之間的聯(lián)動(dòng)規(guī)則改了、審核金額超過兩萬時(shí)要出現(xiàn)額外說明框。每一次改動(dòng)都要定位到對(duì)應(yīng)組件改完還得人工驗(yàn)證周邊邏輯。同一份客戶名稱字段的定義會(huì)散落在搜索頁、創(chuàng)建頁、詳情頁、編輯頁改一處漏三處是常態(tài)。另一條路是上低代碼表單引擎可視化拖拽、自動(dòng)生成代碼、內(nèi)置一堆高級(jí)組件。聽起來很美好真用起來卻經(jīng)常被綁架。引擎自帶的表達(dá)式語法要學(xué)數(shù)據(jù)流是引擎自己的規(guī)則組件版本跟著引擎走想嵌入一個(gè)自定義的業(yè)務(wù)組件還得看引擎給你留了多少縫隙。很多團(tuán)隊(duì)花了兩三周接入最后又花了兩三周把表單遷回普通組件因?yàn)榫€上報(bào)問題的速度已經(jīng)趕不上需求變更的速度了。這兩條路的本質(zhì)矛盾是一樣的表單的定義和表單的執(zhí)行被綁死在了一起。要么把定義寫進(jìn)代碼里導(dǎo)致處處復(fù)制要么把執(zhí)行塞進(jìn)引擎里導(dǎo)致處處受限。AutoForm 的雙層架構(gòu)就是為了解開這個(gè)結(jié)。1.2 雙層架構(gòu)的核心分界schema 是數(shù)據(jù)renderer 是代碼AutoForm 的整個(gè)架構(gòu)只有兩個(gè)概念。上層是 schema也就是表單定義。它是一份純數(shù)據(jù)描述有哪些字段、字段類型、布局順序、校驗(yàn)規(guī)則、聯(lián)動(dòng)條件。schema 本身沒有副作用不依賴某個(gè) UI 組件庫也不需要運(yùn)行環(huán)境。它可以放在前端項(xiàng)目里可以從后端接口下發(fā)也可以直接存在數(shù)據(jù)庫里。下層是 renderer也就是表單執(zhí)行器。它是一段代碼負(fù)責(zé)讀取 schema、找到對(duì)應(yīng)組件、管理字段值、觸發(fā)校驗(yàn)、執(zhí)行聯(lián)動(dòng)結(jié)果。renderer 可以有多個(gè)實(shí)現(xiàn)同一個(gè) schema 在表單頁、詳情頁、搜索頁里可以渲染出完全不同的界面。中間連接兩層的是一個(gè)非常簡單的創(chuàng)建入口傳入 schema指定視圖類型附加運(yùn)行環(huán)境。這個(gè)入口返回一個(gè)表單實(shí)例實(shí)例上只掛幾個(gè)必要的方法。我把這兩層之間的契約控制得很小因?yàn)槠跫s越大使用者需要理解的東西就越多架構(gòu)也就越不容易保持輕量。我經(jīng)常給同事們打一個(gè)比方schema 是圖紙renderer 是施工隊(duì)。圖紙不關(guān)心施工隊(duì)用哪家的磚施工隊(duì)可以根據(jù)同一個(gè)圖紙蓋住宅樓、蓋辦公室、蓋臨時(shí)展廳。AutoForm 做的事情就是讓圖紙和施工隊(duì)保持獨(dú)立同時(shí)約定一張圖紙上每個(gè)符號(hào)的含義。層級(jí)內(nèi)容典型職責(zé)是否可運(yùn)行Schema 層字段、布局、校驗(yàn)、聯(lián)動(dòng)數(shù)據(jù)定義、跨端復(fù)用、后端下發(fā)否Renderer 層組件映射、值管理、事件驅(qū)動(dòng)界面渲染、表單交互、校驗(yàn)執(zhí)行是2. Schema 層只描述“長什么樣、要什么”不描述“怎么實(shí)現(xiàn)”schema 層的設(shè)計(jì)目標(biāo)不是做一個(gè)完整的領(lǐng)域建模語言而是提供一個(gè)夠用的表單描述協(xié)議。這個(gè)協(xié)議必須讓產(chǎn)品經(jīng)理能讀讓后端能生成讓前端能渲染讓測試能理解。AutoForm 的 schema 內(nèi)部統(tǒng)一用對(duì)象表示最外層固定包含 version 字段這樣以后協(xié)議演進(jìn)時(shí)有據(jù)可查。2.1 字段描述的基本協(xié)議每個(gè)字段由一個(gè)字段對(duì)象描述核心字段如下表。AutoForm 的組件注冊(cè)表里有一個(gè)字符串和組件的映射關(guān)系所以 schema 里只需要寫組件名不需要寫任何導(dǎo)入路徑或者組件對(duì)象。字段屬性類型說明namestring字段名提交時(shí)作為值的 keylabelstring展示給用戶看的標(biāo)簽componentstring組件注冊(cè)名例如 Input、NumberInputpropsobject傳給 UI 組件的額外參數(shù)rulesarray校驗(yàn)規(guī)則列表hiddenboolean初始是否隱藏disabledboolean初始是否禁用descriptionstring字段說明通常在詳情頁展示舉個(gè)例子一個(gè)很常規(guī)的訂單審核表單結(jié)構(gòu)大概長這樣{ version: 1.0, fields: [ { name: orderNo, label: 訂單號(hào), component: Input, props: { placeholder: 請(qǐng)輸入訂單號(hào) }, rules: [ { required: true, message: 訂單號(hào)不能為空 } ] }, { name: amount, label: 審核金額, component: NumberInput, props: { precision: 2 } }, { name: payType, label: 支付方式, component: Select, props: { options: [ { label: 在線支付, value: online }, { label: 線下轉(zhuǎn)賬, value: transfer }, { label: 退款沖抵, value: refund } ] } } ] }這里有個(gè)值得注意的設(shè)計(jì)決策schema 里的label、placeholder這類信息必須是純數(shù)據(jù)不參與任何邏輯判斷。邏輯判斷只圍繞name和value展開這樣 schema 才能被后端安全地解析和生成不會(huì)因?yàn)槟硞€(gè)字段被 UI 文案污染而影響業(yè)務(wù)邏輯。2.2 布局信息用二維數(shù)組表達(dá)很多表單描述協(xié)議會(huì)把布局打成樹形結(jié)構(gòu)比如柵格、分組、卡片層層嵌套。樹形結(jié)構(gòu)表達(dá)能力強(qiáng)但寫起來重處理起來也要遞歸。AutoForm 選擇了一個(gè)更樸素的方案layout 字段是一個(gè)二維數(shù)組。第一層是行第二層是這一行里的字段。{ layout: [ [orderNo], [amount, payType] ] }上面的 layout 表示第一行只有訂單號(hào)第二行是金額和支付方式并排。約定每個(gè)字段名在 layout 里最多出現(xiàn)一次沒出現(xiàn)在 layout 里的字段自動(dòng)按 fields 的聲明順序追加到末尾。這個(gè)設(shè)計(jì)有意犧牲了復(fù)雜嵌套能力換來了三個(gè)好處schema 肉眼可讀、后端生成邏輯簡單、前端渲染只需要兩層循環(huán)。如果之后確實(shí)需要分組和卡片我在實(shí)踐中建議不要擴(kuò)展 layout 本身而是在 fields 外面加一個(gè)sections數(shù)組section 內(nèi)部再引用字段名。這樣舊的解析邏輯可以保持穩(wěn)定新能力只是增量不會(huì)破壞已有 schema。2.3 聯(lián)動(dòng)規(guī)則走聲明式不走腳本表單聯(lián)動(dòng)是最容易把架構(gòu)搞重的點(diǎn)。我看到不少方案在 schema 里塞 JavaScript 表達(dá)式運(yùn)行的時(shí)候用eval或者一個(gè)自定義解釋器去執(zhí)行。這么做功能很強(qiáng)大但隨之而來的是調(diào)試?yán)щy、安全風(fēng)險(xiǎn)、性能損耗。表達(dá)式的字符串寫在 JSON 里寫的時(shí)候沒語法高亮線上報(bào)錯(cuò)了你也很難定位是哪一段表達(dá)式出了問題。AutoForm 的取舍是只支持非常有限的聯(lián)動(dòng)原語。一個(gè)聯(lián)動(dòng)規(guī)則由三部分組成觸發(fā)源、觸發(fā)條件、動(dòng)作。比如支付方式等于退款沖抵時(shí)隱藏金額字段可以這樣描述{ relations: [ { source: payType, condition: { op: eq, value: refund }, action: { type: setVisibility, target: amount, visible: false } } ] }我最初只定義了三種動(dòng)作setVisibility、setDisabled、setValue。后來業(yè)務(wù)里遇到了需要重置字段值、聯(lián)動(dòng)清空、動(dòng)態(tài)修改選項(xiàng)的場景又增加了resetValue和updateProps。但直到今天AutoForm 的 rules 引擎也不支持任意表達(dá)式。如果你需要A 大于 100 且 B 不等于 x這種條件就拆成兩條 relation或者用一個(gè)自定義的判斷函數(shù)掛進(jìn)去。這個(gè)取舍讓核心包常年保持在小體積也讓 schema 可以安全地交給非前端團(tuán)隊(duì)維護(hù)。2.4 version 字段和 schema 校驗(yàn)schema 既然是數(shù)據(jù)它就會(huì)面臨版本演進(jìn)。AutoForm 在最外層強(qiáng)制要求 version 字段渲染器根據(jù) version 決定用哪個(gè)解析版本。我自己見過太多因?yàn)樽侄味x升級(jí)導(dǎo)致舊數(shù)據(jù)渲染崩潰的事故所以 version 就像數(shù)據(jù)庫表的版本號(hào)一樣必須顯式聲明。校驗(yàn)這部分AutoForm 內(nèi)置了一個(gè)輕量的 schema 校驗(yàn)器主要檢查四類問題字段 name 是否重復(fù)、layout 是否引用了不存在的字段、component 名稱是否有對(duì)應(yīng)注冊(cè)、rules 里的 required 和 pattern 是否合法。這層校驗(yàn)不查業(yè)務(wù)邏輯只查結(jié)構(gòu)健康度。每次從后端拉取 schema 時(shí)先跑一遍校驗(yàn)?zāi)茉阡秩厩熬蛿r截掉 80% 的配置錯(cuò)誤。3. Renderer 層同一份 schema三種渲染方式的復(fù)用實(shí)驗(yàn)如果說 schema 層是 AutoForm 的靜面renderer 層就是動(dòng)面。renderer 負(fù)責(zé)把同一份 schema 變成可交互的界面同時(shí)保持不同場景之間的行為一致。3.1 渲染器注冊(cè)表和創(chuàng)建入口AutoForm 的渲染器采用注冊(cè)表模式。每個(gè) renderer 對(duì)象包含一個(gè) view 標(biāo)識(shí)和一個(gè) render 方法通過AutoForm.register注冊(cè)進(jìn)去。創(chuàng)建表單實(shí)例時(shí)通過AutoForm.create指定 view 類型。這里你可以把 view 理解成使用者希望表單以什么形態(tài)出現(xiàn)的開關(guān)。AutoForm.register({ view: form, render: (schema, context) { return FormRenderer schema{schema} context{context} /; } }); const instance AutoForm.create(schema, { view: form, componentMap, value: initialValue, onChange: (nextValue) console.log(nextValue) });創(chuàng)建入口是兩層的唯一連接點(diǎn)。無論 renderer 內(nèi)部多復(fù)雜對(duì)外暴露的能力都收斂在一組方法上getValue、setValue、validate、reset。業(yè)務(wù)方不需要知道當(dāng)前是哪個(gè) renderer 在干活也不需要知道 schema 是怎么被解析的。3.2 form / detail / search 三種視圖渲染器我實(shí)際用得最多的三個(gè) view 分別是表單、詳情、搜索。表單和詳情兩個(gè) renderer 是同一個(gè)代碼倉庫里最互補(bǔ)的兩個(gè)實(shí)現(xiàn)。表單渲染器會(huì)把 layout 攤開成柵格每個(gè)字段渲染對(duì)應(yīng)的輸入組件同時(shí)掛上校驗(yàn)規(guī)則。詳情渲染器接同一份 schema把字段名映射成 label把字段值交給一個(gè) Format 函數(shù)格式化后輸出。也就是說同一個(gè)訂單號(hào)字段表單里是一個(gè)輸入框詳情里是一行只讀文本。這種一致性不是靠復(fù)制粘貼實(shí)現(xiàn)的而是因?yàn)閮烧吖蚕硗环?schema 定義。搜索渲染器稍微特殊一點(diǎn)。它不會(huì)渲染完整字段而是從 schema 里挑出searchable: true的字段。我在 schema 字段協(xié)議里加了searchable這個(gè)可選標(biāo)記目的是讓搜索條件跟表單字段天然保持同步。訂單號(hào)、客戶名這種高頻搜索條件在 schema 里標(biāo)上searchable搜索表單就自動(dòng)生成不用單獨(dú)維護(hù)另一套搜索字段定義。渲染器輸入組件校驗(yàn)規(guī)則布局支持主要用途form是是二維數(shù)組布局新增、編輯、審核detail否否label 對(duì)齊詳情展示、審批預(yù)覽search部分字段否簡單橫向排列列表?xiàng)l件篩選3.3 自定義組件的統(tǒng)一接入?yún)f(xié)議AutoForm 不內(nèi)置任何 UI 組件所以組件接入?yún)f(xié)議是 renderer 層能否落地的關(guān)鍵。每個(gè)自定義組件只需要遵循一個(gè)簡單的 props 契約接收value作為當(dāng)前值調(diào)用onChange傳出新值同時(shí)支持disabled、readOnly這類通用狀態(tài)。至于組件內(nèi)部是用什么 UI 庫實(shí)現(xiàn)的AutoForm 完全不關(guān)心。interface FieldComponentProps { name: string; value: unknown; onChange: (value: unknown) void; disabled?: boolean; readOnly?: boolean; [key: string]: unknown; } const MyAmountInput: React.FCFieldComponentProps ({ value, onChange, disabled, ...restProps }) { return input typetext value{value ?? } disabled{disabled} onChange{(e) onChange(e.target.value)} {...restProps} /; };這個(gè)協(xié)議雖然簡單但要求組件必須是受控組件也就是值由外部傳入組件內(nèi)部不維護(hù)數(shù)據(jù)副本。我在推廣時(shí)遇到過很多組件天然是內(nèi)部維護(hù)狀態(tài)的改造起來有一定成本。這塊沒有更好的捷徑只能靠統(tǒng)一封裝層去兜底。建議團(tuán)隊(duì)在建組件庫時(shí)就把 value/onChange 契約納入規(guī)范否則后接 AutoForm 時(shí)要返工。4. “輕量級(jí)”是怎么取舍的我砍掉的重概念做架構(gòu)時(shí)最難的往往不是加功能而是決定砍掉什么。AutoForm 被稱為輕量級(jí)不是因?yàn)楣δ苌偎源a量小而是我主動(dòng)砍掉了四個(gè)容易讓架構(gòu)變重的設(shè)計(jì)。4.1 不內(nèi)置 UI 組件庫一開始有人建議直接把 Ant Design 或者 Element 封裝進(jìn) AutoForm這樣開箱即用。我拒絕了這條路線。內(nèi)置 UI 庫看起來方便實(shí)際上意味著 AutoForm 的生命周期被綁定在一個(gè)框架版本鏈路上。今天項(xiàng)目用的 AntD v4明天升級(jí) v5AutoForm 要么跟著升級(jí)要么成為一個(gè)兼容層黑洞。AutoForm 的做法是把組件映射交出來。外界通過 componentMap 傳入一個(gè){ Input, Select, DatePicker }對(duì)象schema 里的 component 字符串在這個(gè)映射表里查找對(duì)應(yīng)組件。組件屬于項(xiàng)目不屬于 AutoFormAutoForm 只提供查找規(guī)則和渲染流程。4.2 不做運(yùn)行時(shí)表達(dá)式引擎表單字段之間的依賴比如金額大于某個(gè)值時(shí)顯示額外字段、多選選中某項(xiàng)時(shí)修改另一項(xiàng)的 options這類需求一旦寫進(jìn)核心就收不住。完整的表達(dá)式引擎要處理語法解析、變量作用域、類型轉(zhuǎn)換、錯(cuò)誤堆棧哪怕只做 JS 的子集復(fù)雜度也會(huì)超過整個(gè)表單渲染流程。所以 AutoForm 選擇了聲明式 relations。條件判斷只支持eq、neq、gt、gte、in這五個(gè)操作符動(dòng)作只支持前文說的那五種。真遇到特別復(fù)雜的聯(lián)動(dòng)判斷我會(huì)建議業(yè)務(wù)方寫一個(gè)自定義 validator 或者自定義computeProps函數(shù)掛到 schema 上。這樣做誠實(shí)且可控核心永遠(yuǎn)不膨脹。4.3 不接管全局狀態(tài)很多表單框架會(huì)把數(shù)據(jù)狀態(tài)管理做進(jìn)內(nèi)核比如內(nèi)部維護(hù)一個(gè) store提供 get/set 方法再和 Redux、Zustand 打通。AutoForm 沒有這么做。值就是普通對(duì)象創(chuàng)建實(shí)例時(shí)傳入 initial value交互過程中由 onChange 把最新值拋回給外界狀態(tài)到底放在組件局部 state 還是全局 store 中由使用方自己決定。這個(gè)決策在很多人看來很偷懶但它幫我避開了大量數(shù)據(jù)同步問題。表單頁面里的值本來就該由頁面控制表單引擎適合做一個(gè)計(jì)算器不適合做賬本。4.4 不做模板編譯和代碼生成還有一種比較重的思路是把 schema 編譯成 React/Vue 代碼然后交付給項(xiàng)目。模板編譯要做代碼生成、語法轉(zhuǎn)換、依賴分析還要處理編譯產(chǎn)物和手寫代碼混合的邊界。AutoForm 只做運(yùn)行時(shí)解析不在構(gòu)建期碰任何代碼。schema 傳進(jìn)來組件直接渲染出來沒有中間產(chǎn)物因此任何環(huán)境都能用包括一些不支持編譯器的低代碼容器。5. 落地復(fù)盤一個(gè)訂單審核頁從 schema 定義到踩坑修復(fù)說了這么多設(shè)計(jì)不落地都是空談。我?guī)Т蠹彝暾咭槐?AutoForm 在實(shí)際項(xiàng)目里做訂單審核頁的過程順便復(fù)盤幾個(gè)我印象很深的坑。5.1 第一步定義訂單審核表單的 schema假設(shè)業(yè)務(wù)方提出的需求是審核員需要查看訂單號(hào)、客戶名稱、支付方式、審核金額、退款原因備注。當(dāng)支付方式選擇退款沖抵時(shí)必須顯示退款原因輸入框?qū)徍私痤~超過 20000 時(shí)備注字段變?yōu)楸靥?。這份 schema 大概長這樣{ version: 1.0, layout: [ [orderNo, customerName], [payType, amount], [refundReason], [remark] ], fields: [ { name: orderNo, label: 訂單號(hào), component: Input }, { name: customerName, label: 客戶名稱, component: Input }, { name: payType, label: 支付方式, component: Select, props: { options: [ { label: 在線支付, value: online }, { label: 線下轉(zhuǎn)賬, value: transfer }, { label: 退款沖抵, value: refund } ] } }, { name: amount, label: 審核金額, component: NumberInput }, { name: refundReason, label: 退款原因, component: TextArea }, { name: remark, label: 審核備注, component: TextArea } ], relations: [ { source: payType, condition: { op: eq, value: refund }, action: { type: setVisibility, target: refundReason, visible: true } }, { source: amount, condition: { op: gt, value: 20000 }, action: { type: updateProps, target: remark, props: { rules: [ { required: true, message: 大額訂單必須填寫審核備注 } ] } } } ] }這里我特別強(qiáng)調(diào) layout 的作用。如果后端下發(fā)接口時(shí)把 JSON 字段順序做了排序前面的 field 數(shù)組順序變了布局也不會(huì)亂因?yàn)殇秩就耆?layout 為準(zhǔn)。這是一層防御性設(shè)計(jì)我們?cè)趯?shí)際聯(lián)調(diào)時(shí)多次從中受益。5.2 第二步注冊(cè)渲染器和組件表頁面?zhèn)冉尤氪a非常短。組件表里放的是項(xiàng)目自己的封裝組件AutoForm 只做渲染編排。const componentMap { Input: AppInput, Select: AppSelect, NumberInput: AppNumberInput, TextArea: AppTextArea, }; const Page () { const [instance, setInstance] useStateFormInstance | null(null); const [value, setValue] useState({}); useEffect(() { const inst AutoForm.create(orderSchema, { view: form, componentMap, value, onChange: setValue, }); setInstance(inst); }, []); const handleSubmit async () { const result await instance?.validate(); if (result?.pass) { // 提交 value } }; return ( div {instance?.render()} button onClick{handleSubmit}提交審核/button /div ); };這里的 FormInstance 接口是固定的renderer 換掉頁面代碼也不用改。比如同一個(gè)頁面需要做只讀審核預(yù)覽時(shí)不需要新建一頁只用把 view 換成detail再創(chuàng)建一次實(shí)例即可。5.3 現(xiàn)場遇到的三個(gè)坑組件 props 覆蓋、聯(lián)動(dòng)環(huán)、id 漂移第一個(gè)坑是組件 props 覆蓋。自定義組件通常有自己的 className、style、data-testid 這類屬性。最開始 renderer 會(huì)把 schema 里的 props 直接展開傳給組件結(jié)果項(xiàng)目里統(tǒng)一的下劃線樣式被 schema 里的props.style覆蓋了好幾個(gè)頁面樣式突然失真。排查鏈路倒是很清晰頁面樣式問題先看傳給組件的 props打印后發(fā)現(xiàn) schema 里的 props 與項(xiàng)目默認(rèn)屬性沖突。修復(fù)方案是在updateProps動(dòng)作之外加了一條規(guī)則組件協(xié)議里的通用屬性比如disabled、readOnly、hidden由 renderer 統(tǒng)一管理自定義 schema props 只允許放進(jìn)extraProps命名空間。這樣組件自身的約定屬性不會(huì)被外部配置隨意覆蓋。第二個(gè)坑是聯(lián)動(dòng)環(huán)。某個(gè)版本里兩個(gè)字段互相設(shè)置 disabled 狀態(tài)一個(gè)是A 被禁用時(shí) B 不禁用另一個(gè)是B 被禁用時(shí) A 不禁用再加上初始值配置沒做好導(dǎo)致渲染時(shí)聯(lián)動(dòng)反復(fù)觸發(fā)最后棧溢出。排查時(shí)我先在 relations 里打印執(zhí)行記錄發(fā)現(xiàn)一個(gè)問題updateProps動(dòng)作執(zhí)行后又會(huì)觸發(fā) source 字段的 watcher進(jìn)而再次執(zhí)行 relation。修復(fù)方式是兩個(gè)層面同時(shí)做。核心層增加執(zhí)行深度限制單次事件循環(huán)內(nèi)最多處理二十條聯(lián)動(dòng)鏈?zhǔn)褂脤用娼钩霈F(xiàn)兩個(gè)字段互相 setDisabled 這種循環(huán)關(guān)系在 schema 校驗(yàn)器里增加了環(huán)檢測?，F(xiàn)在 AutoForm 遇到循環(huán)關(guān)系時(shí)會(huì)在創(chuàng)建階段直接報(bào)錯(cuò)而不是等到運(yùn)行期才表現(xiàn)異常。第三個(gè)坑是詳情頁的 id 漂移。detail 渲染器為了實(shí)現(xiàn) label 和值一一對(duì)應(yīng)生成了一組基于字段名的 id。當(dāng)同一頁面有兩個(gè)相同 schema 實(shí)例時(shí)比如左右對(duì)比審核兩邊的 label 和值會(huì)錯(cuò)位。這個(gè)問題的根因是 id 沒有實(shí)例化作用域。后來我在創(chuàng)建入口增加了一個(gè) scopeId 參數(shù)所有內(nèi)部生成的 DOM id 都以 scopeId 為前綴這個(gè)問題才徹底消掉。5.4 排查鏈路回顧這三個(gè)坑讓我總結(jié)出一條經(jīng)驗(yàn)雙層架構(gòu)的問題大多數(shù)發(fā)生在契約邊緣而不是 schema 本身或 renderer 內(nèi)部。所以排查問題時(shí)要先問三個(gè)問題字段名是否存在于 schema組件是否注冊(cè)在 componentMap當(dāng)前 view 是否有對(duì)應(yīng)的 renderer 注冊(cè)把這三條走完一般能找到 80% 的根因。問題表現(xiàn)檢查順序常見根因組件沒渲染schema 字段名 - componentMapcomponent 字符串拼寫錯(cuò)誤樣式錯(cuò)亂組件通用屬性 - extraPropsprops 直接展開覆蓋聯(lián)動(dòng)卡死relation 環(huán)檢測 - 執(zhí)行深度兩個(gè)字段互相設(shè)置狀態(tài)狀態(tài)不更新onChange 是否透傳 - value 是否受控自定義組件內(nèi)部維護(hù)自己的 state值提交缺失字段是否 hidden 且未排除隱藏字段沒配 ignore 策略6. 雙層架構(gòu)的適用邊界以及它和輕量級(jí)工作流的關(guān)系架構(gòu)沒有絕對(duì)好壞只有適用邊界。做完 AutoForm 之后我越來越清楚什么場景該用它什么場景最好不要硬套。6.1 我建議使用 AutoForm 的場景最典型的場景是后臺(tái)管理系統(tǒng)尤其是表單數(shù)量多、字段相似度高、變更頻繁的團(tuán)隊(duì)。把 schema 從代碼里抽出來之后前端可以更快響應(yīng)產(chǎn)品改字段的需求產(chǎn)品經(jīng)理甚至可以直接改一份 JSON 文件發(fā)起 MR測試同學(xué)也能在提測前先自行校驗(yàn) schema 結(jié)構(gòu)。我第二個(gè)重點(diǎn)推薦的使用場景是動(dòng)態(tài)表單。比如表單模板由用戶配置或者表單內(nèi)容由后端按業(yè)務(wù)類型下發(fā)這種場景天生就需要 schema 與 renderer 分離。AutoForm 的 schema 是純 JSON后端可以基于權(quán)限、業(yè)務(wù)類型拼裝不同的字段集合前端只需要處理渲染和數(shù)據(jù)回傳不需要跟著每個(gè)業(yè)務(wù)類型寫死組件。跨端渲染也值得提。同一份訂單 schemaPC 后臺(tái)是表格布局移動(dòng)端審批 App 是縱向排列的卡片布局。移動(dòng)端備注欄更寬詳情頁更緊湊。因?yàn)?schema 與 UI 組件庫無關(guān)兩個(gè)端可以各自注冊(cè)自己的組件映射但字段名、校驗(yàn)規(guī)則、提交結(jié)構(gòu)完全一致。6.2 不建議強(qiáng)行上 AutoForm 的場景如果項(xiàng)目里只有三五個(gè)固定表單而且?guī)缀醪粫?huì)變動(dòng)我不建議引入 AutoForm。加一層抽象必然帶來理解成本直接寫組件反而更簡單。復(fù)雜的動(dòng)態(tài)嵌套表單比如一個(gè)可以無限增加行、每行內(nèi)部又有子表結(jié)構(gòu)的矩陣場景AutoForm 的二維 layout 是撐不住的。這種場景更適合專門的數(shù)據(jù)網(wǎng)格方案。AutoForm 的價(jià)值是通用表單不是萬能編輯器。對(duì)實(shí)時(shí)協(xié)同編輯這類極端場景也有壓力。AutoForm 的 value 是整體對(duì)象多人同時(shí)編輯同一個(gè)表單時(shí)字段級(jí)合并沖突要外界自己處理。如果要做到 OT 或者 CRDT表單引擎本身不應(yīng)該是核心瓶頸而是你整體架構(gòu)里微不足道的一部分沒必要糾結(jié)在渲染層。6.3 雙層架構(gòu)只是輕量級(jí)工作流的底座最后聊一個(gè)讓我自己都覺得驚喜的延伸。AutoForm 最初只是做表單后來團(tuán)隊(duì)做審批流時(shí)發(fā)現(xiàn)一個(gè)簡單的審核流程本質(zhì)上就是多個(gè) schema 節(jié)點(diǎn)的有序流轉(zhuǎn)。步驟一填申請(qǐng)單步驟二管理員審核步驟三財(cái)務(wù)打款每個(gè)步驟對(duì)應(yīng)一份 schema再加上一個(gè)狀態(tài)機(jī)描述步驟之間的跳躍條件就構(gòu)成了一套非常輕量級(jí)的工作流。輕量級(jí)工作流的關(guān)鍵在于每個(gè)節(jié)點(diǎn)只依賴 schema不依賴特定頁面代碼。工作流引擎只關(guān)心當(dāng)前節(jié)點(diǎn)是誰、下一步是誰、需要校驗(yàn)什么數(shù)據(jù)具體的字段交互全部交給 AutoForm 渲染。這樣審批流的調(diào)整往往只需要改配置和 schema不需要改前端代碼。從雙層架構(gòu)到輕量級(jí)工作流中間隔著的只是規(guī)則的顯式化。我現(xiàn)在的做法是把每一類表單的 schema 集中放在一個(gè)表單倉庫目錄里用 JSON 文件維護(hù)并提供版本變更記錄。當(dāng)需求方說這個(gè)表單需要加一個(gè)字段我改的是 schema 文件跑的是結(jié)構(gòu)校驗(yàn)然后界面自己就跟著變了。這個(gè)流程看起來不夠炫酷但它讓表單開發(fā)真正回歸到了數(shù)據(jù)配置本身我覺得這才是輕量級(jí)里輕字的分量。