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