表單的核心作用是支持用戶提交信息，無論是SaaS產(chǎn)品，還是內(nèi)部工具，或是C端產(chǎn)品，表單都是不可或缺的一部分。表單如此重要，以至于很多低代碼產(chǎn)品本質(zhì)上就是表單驅(qū)動型的產(chǎn)品，開發(fā)者在搭建表單的同時，也定義了應(yīng)用的數(shù)據(jù)模型。本文作者分享了低代碼的表單設(shè)計(jì)，一起來看一下吧。

你可能不太了解什么是表單，但它在你的日常生活中已經(jīng)無處不在。當(dāng)我們注冊商場會員時，需要填寫個人信息，這時你正在填寫的，就是表單；當(dāng)我們在運(yùn)營后臺新錄入一條商品數(shù)據(jù)時，我們填寫的也是表單。

表單的核心作用是支持用戶提交信息。無論是 SaaS 產(chǎn)品，還是內(nèi)部工具，或是 C 端產(chǎn)品，表單都是不可或缺的一部分。

表單如此重要，以至于很多低代碼產(chǎn)品本質(zhì)上就是表單驅(qū)動型的產(chǎn)品，例如輕流、簡道云等，開發(fā)者在搭建表單的同時，也定義了應(yīng)用的數(shù)據(jù)模型。

本文主要與大家分享低代碼中的表單設(shè)計(jì)，所分享內(nèi)容來自我在所負(fù)責(zé)的表單項(xiàng)目中積累的實(shí)踐經(jīng)驗(yàn)，如果偏頗，請多包涵。

如果你負(fù)責(zé)低代碼相關(guān)產(chǎn)品，那本文對你從事表單設(shè)計(jì)會有所幫助，如果你是 B 端產(chǎn)品，本文亦能對你有所啟發(fā)。

國內(nèi)的低代碼產(chǎn)品有兩種核心路線：一種是表單驅(qū)動型，其應(yīng)用搭建思路是表單+流程，一般適用于簡單的業(yè)務(wù)場景；一種是模型驅(qū)動型，其應(yīng)用搭建思路是數(shù)據(jù)模型+頁面+流程，一般適用于更復(fù)雜的業(yè)務(wù)場景。

鑒于筆者的實(shí)踐經(jīng)驗(yàn)，本文主要分享模型驅(qū)動型低代碼產(chǎn)品中的表單設(shè)計(jì)，但我相信對表單驅(qū)動型產(chǎn)品也是有借鑒意義的。

一

聊表單，首先要聊數(shù)據(jù)模型。

前面說到，表單的核心作用是支持用戶提交信息。大多數(shù)時候，這些信息是需要記錄在數(shù)據(jù)庫的，例如會員信息、商品信息等，信息提交到記錄在數(shù)據(jù)庫的過程，我們簡稱為「落庫」。

那需要提交什么樣的信息，取決于這個信息本身所關(guān)聯(lián)的表是什么結(jié)構(gòu)，而表的結(jié)構(gòu)，核心在于字段是什么類型。（這里涉及一些數(shù)據(jù)庫的知識，我就不展開了）

歸根到底一句話，啟動表單設(shè)計(jì)前，需要搞清楚當(dāng)前低代碼產(chǎn)品的數(shù)據(jù)模型有哪些能力。更直接一些，就是搞清楚支持哪些數(shù)據(jù)字段，每種字段的屬性到底如何。

在 Js 中，常見的五種數(shù)據(jù)字段類型分別是：string、number、boolean、null、undefined，而在低代碼中，如果直接根據(jù)這五種原始字段類型設(shè)計(jì)表單，則基本不可用。

舉個例子，姓名和郵箱都是string 類型的信息，但他們的錄入體驗(yàn)和校驗(yàn)規(guī)則完全不一樣，很難在同一種規(guī)范下進(jìn)行設(shè)計(jì)。

所以，很多低代碼產(chǎn)品會在原始數(shù)據(jù)字段類型的基礎(chǔ)上，進(jìn)一步封裝一層業(yè)務(wù)數(shù)據(jù)字段，常見的包括：文本、富文本、數(shù)字、日期、日期時間、選項(xiàng)、文件、布爾、手機(jī)號、郵箱、圖片等等。

需要支持哪些字段并沒有統(tǒng)一的規(guī)則，唯一需要考慮的是，新增一種字段類型帶來的收益，是否大于與之對應(yīng)的開發(fā)成本，即可。

二

在數(shù)據(jù)模型之上，我們需要進(jìn)一步考慮表單項(xiàng)。

在用戶輸入信息的過程中，需要提供一些額外的能力來幫助填寫，其中最重要的就是校驗(yàn)和提示。而表單項(xiàng)，就是承載字段輸入、校驗(yàn)和提示這三個能力的一類組件。

字段輸入：提供對應(yīng)的輸入控件，支持用戶完成信息輸入。例如文本輸入框，其在移動端的交互就是用戶點(diǎn)擊輸入框后，喚起鍵盤，完成文本信息輸入后，信息回填在輸入框內(nèi)。

校驗(yàn)：對用戶輸入信息按照一定規(guī)則做校驗(yàn)，例如中國大陸手機(jī)號的長度必須是 11 位。校驗(yàn)是表單中十分重要的能力，因?yàn)楸韱螖?shù)據(jù)如果要落庫的話，需要盡可能保障數(shù)據(jù)庫中數(shù)據(jù)的規(guī)范性，避免引入無效數(shù)據(jù)。

提示：為了優(yōu)化用戶填寫表單的體驗(yàn)，很多時候填寫的字段旁邊會有一些解釋文案。這部分文案的配置也是在表單項(xiàng)內(nèi)完成。

在表單項(xiàng)的設(shè)計(jì)過程中，我們需秉持一個原則：任何一種已有的字段，都必須有對應(yīng)的表單項(xiàng)，才能保障數(shù)據(jù)的正常流轉(zhuǎn)。

因此，如果要從 0 到 1 設(shè)計(jì)表單，表單項(xiàng)的設(shè)計(jì)是最開始也是工作量最大的一步。只有保證表單項(xiàng)是完備的，我們才能考慮下一步：表單的設(shè)計(jì)。

需要說明的是，表單項(xiàng)的設(shè)計(jì)也有兩種不同的思路：一體化和原子化。

一體化的思路中，所有的屬性都在表單項(xiàng)的配置中完成。例如字段的 label、校驗(yàn)規(guī)則、表單項(xiàng)中輸入控件的樣式等，這種思路的好處是操作成本更低，在一個地方集中完成配置。與之對應(yīng)的，其缺點(diǎn)也很明顯，就是不夠靈活。

而原子化的思路，就是表單項(xiàng)是一個復(fù)合的組件，其中的字段 label、提示文案、校驗(yàn)文案、輸入控件等，都可以單獨(dú)選中配置。這樣的設(shè)計(jì)思路下，表單項(xiàng)的靈活性會非常高，當(dāng)然使用成本也隨之升高。

具體選擇哪種思路，得需要跟當(dāng)前低代碼產(chǎn)品的整體設(shè)計(jì)原則匹配。

三

表單項(xiàng)完備了，下面就要進(jìn)入最核心的環(huán)節(jié)：表單容器的設(shè)計(jì)。

表單容器是模型驅(qū)動型低代碼產(chǎn)品特有的組件。因?yàn)槭墙M件，所以它的層級比頁面更低，這也就意味著，一個表單不是一個頁面，而是頁面中的一個模塊。

表單容器是一個數(shù)據(jù)容器組件，對這個組件來說，需要綁定某個數(shù)據(jù)源，這是組件的輸入；而組件的輸出就是與數(shù)據(jù)源對應(yīng)的一條記錄。

表單的提交，就是將表單輸出的數(shù)據(jù)在下游進(jìn)行流轉(zhuǎn)：傳遞到其他頁面或流程中使用，或者是直接落庫。

從邏輯上說，當(dāng)我們有了表單項(xiàng)之后，就已經(jīng)具備了搭建出一個表單所需要的全部能力了。但這種搭建成本會非常高，需要字段 by 字段地去流轉(zhuǎn)數(shù)據(jù)。

而表單容器組件的目的，就是最大程度降低表單搭建的門檻，提升它的易用性。那它是怎么做到的呢？這就不得不說到模型驅(qū)動。

四

模型驅(qū)動低代碼產(chǎn)品的典范是微軟的Powerapps（如果你想做低代碼，建議多研究它），我對模型驅(qū)動的理解是，圍繞模型做應(yīng)用搭建。

為了方便你的理解，我以前面提到的商品數(shù)據(jù)維護(hù)為例做說明。

對于商品來說，它的數(shù)據(jù)模型就是它的主數(shù)據(jù)。比如商品的名稱、定價(jià)、所屬品牌、生產(chǎn)日期等等，所有與商品有關(guān)的信息，且在系統(tǒng)中需要用到并維護(hù)的信息，最終都落在一張表上。

可以認(rèn)為，這張表就是商品背后的數(shù)據(jù)模型。

模型驅(qū)動的意思是，在應(yīng)用搭建時，圍繞商品的數(shù)據(jù)源快速生成數(shù)據(jù)獲取、展示、落庫等核心模塊，即：

模型是表單內(nèi)的最小單位。

如果你去體驗(yàn) Powerapps 就會發(fā)現(xiàn)，當(dāng)我們將表單關(guān)聯(lián)某個數(shù)據(jù)源時，就會自動生成對應(yīng)的表單項(xiàng)，且表單項(xiàng)的默認(rèn)配置與字段在數(shù)據(jù)庫中的屬性對應(yīng)。

例如，如果字段是必填，則表單項(xiàng)的校驗(yàn)規(guī)則中也會默認(rèn)必填。

Powerapps 做得更徹底，當(dāng)表單生成后，表單項(xiàng)默認(rèn)是鎖住的狀態(tài)，如果需要修改，首先需要解鎖。這無疑傳遞了一個很強(qiáng)的信號：

系統(tǒng)已經(jīng)根據(jù)數(shù)據(jù)源的特征幫你生成了表單，肯定好用，沒事不要亂改。

當(dāng)表單提交時，Powerapps 也會執(zhí)行 submit 函數(shù)，函數(shù)的參數(shù)是 form ，這里的意思也很明顯：數(shù)據(jù)提交背后，真正進(jìn)行數(shù)據(jù)流轉(zhuǎn)的是模型，而不是表單項(xiàng)代表的字段。

當(dāng)我們嘗試向表單內(nèi)拖入一個輸入控件后，會發(fā)現(xiàn)這個控件完全是游離在表單之外的存在，與表單本身沒有任何關(guān)系。

因?yàn)椋@個獨(dú)立的輸入控件不是由模型控制的，跟模型沒有任何關(guān)系。因此在模型驅(qū)動的思路下，這樣的產(chǎn)品邏輯無疑是非常合理的。

老實(shí)說，第一次使用的時候我覺得很奇怪，似乎這里的表單不是那么靈活，哪哪都限制了。但真正弄懂背后的邏輯后，我無比為它的嚴(yán)謹(jǐn)和一致性而嘆服。

我見過很多功能大而全的產(chǎn)品，典型的「既要又要」邏輯下的產(chǎn)物。你說不上好用，也說不上難用，但就是沒什么記憶點(diǎn)。

而用過一些優(yōu)秀且經(jīng)典的產(chǎn)品后，我發(fā)現(xiàn)，能將某種設(shè)計(jì)原則從始至終貫徹到底的產(chǎn)品，才真正令人佩服。

順便說說，表單的落庫設(shè)計(jì)比較簡單，基本都是 SQL 相關(guān)語法的產(chǎn)品化，包括insert、update、upsert 等操作，在產(chǎn)品設(shè)計(jì)上按語法要求指定對應(yīng)的參數(shù)即可。

例如，insert 操作只需要指定要插入的數(shù)據(jù)和表即可，但 update 操作需要指定更新的數(shù)據(jù)源、更新前的數(shù)據(jù)以及更新后的數(shù)據(jù)。

普遍的做法是，將 SQL 相關(guān)語法包裝為對應(yīng)的數(shù)據(jù)源方法，在表單提交時調(diào)用對應(yīng)的方法，按要求配置方法的入?yún)⒓纯伞?/p>

五

以上都是從應(yīng)用搭建的角度聊聊低代碼中對應(yīng)的表單設(shè)計(jì)。事實(shí)上，表單作為一種在不同業(yè)務(wù)中都經(jīng)常用到的工具，其擴(kuò)展性遠(yuǎn)不止于此。

其中我認(rèn)為最需要關(guān)注的一點(diǎn)是，表單字段的聯(lián)動。

聯(lián)動場景隨處可見，例如當(dāng)我在性別選項(xiàng)中選擇了男性時，我的衣服尺碼可能就默認(rèn)為 L，選擇女性時，就默認(rèn)為 S。

性別字段和尺碼字段本來是兩個獨(dú)立的字段，但如果尺碼的默認(rèn)值能夠根據(jù)性別字段的值而改變，則對于填寫者來說，體驗(yàn)會好很多。這樣的例子非常多見。

在非低代碼場景下的產(chǎn)品設(shè)計(jì)中，產(chǎn)品經(jīng)理一般會將這樣的聯(lián)動邏輯用語言甚至是流程圖描述清楚，然后開發(fā)用代碼實(shí)現(xiàn)。

但是在低代碼場景下，我們需要實(shí)現(xiàn)的能力是，讓開發(fā)者能通過不寫代碼的方式，配置出它想要的任何聯(lián)動效果。

這里順便說下，低代碼產(chǎn)品經(jīng)理的思維模式與普通產(chǎn)品經(jīng)理的不同在于，面對業(yè)務(wù)訴求時，他們思考的不是需求的實(shí)現(xiàn)邏輯，而是實(shí)現(xiàn)該需求背后的工具的組裝邏輯。

就好像我們經(jīng)常用的那個比喻，用戶需要光，普通產(chǎn)品經(jīng)理便給他們一把合適的錘子，可以鑿壁偷光，但低代碼產(chǎn)品經(jīng)理考慮的是，如果這個用戶想到大錘子，那個用戶想要小錘子，我該如何提供樂高玩具一般的工具，讓他們自己組裝錘子。

說回字段聯(lián)動，其本質(zhì)是 A 表單項(xiàng)中的某些屬性配置需要消費(fèi)到 B 表單項(xiàng)里的信息。依賴兩個底層能力：

1. 表單項(xiàng)的屬性需要可以綁定動態(tài)數(shù)據(jù)。這一點(diǎn)可以參考 powerapps 的設(shè)計(jì)，組件的所有屬性都可以綁定公式。
2. 表單項(xiàng)的屬性支持暴露被消費(fèi)。結(jié)合 1，整個鏈路就是，當(dāng)表單項(xiàng) A 的屬性在綁定公式時，可以在公式中引用表單項(xiàng) B 的屬性。

再結(jié)合我們上面的例子，尺碼字段有一個屬性是 default value，它可以綁定一個公式，公式的邏輯是：如果性別字段的 value 是男，則公式返回 L，如果是女，則返回 S。

這樣，上述的聯(lián)動邏輯就搭建完成了。

而更多更復(fù)雜的邏輯，也是在這兩個底層能力的基礎(chǔ)上完成。后面有機(jī)會我也會詳細(xì)說說這兩個底層能力的產(chǎn)品化設(shè)計(jì)。

尾聲

關(guān)于低代碼產(chǎn)品中的表單設(shè)計(jì)，就分享到這里。最后想說的是，低代碼產(chǎn)品很難做，你可以看到，光是業(yè)務(wù)中常見的表單工具，背后的無代碼邏輯就有這么復(fù)雜。

但另一方面，在如此深的地方去思考需求實(shí)現(xiàn)邏輯，能幫助我們對需求本身理解得更徹底，這也是做低代碼的樂趣之一。