CabinX：表单的本质是什么？

编者按：本文来自微信公众号“多点零售联合云”（ID:Dmall-lhy），作者：李骏，36氪经授权发布。

简介

在B端业务系统中，表单组件十分常见，在功能上也大相径庭，但面对上千人维护的上千张页面中，一个基本的表单在交互及视觉上竟出现千奇百怪交互，无论在用户认知还是使用上都带来不小困扰，为了保证界面整齐划一、交互有迹可循，我们不得不通过大量人工走查保证一个巨石应用整体交互、UI整齐划一。为此多点CabinX基于本质设计对表单提出了一些自己的思考。

B端设计中市面上表单方案存在的困局

表单主要负责数据采集功能，一个表单包含一个或多个输入元素、提交&复位等表单按钮。无论在W3C规范还是Boostrap、AntD、Element等常见UI组件库中，都允许表单中编写用于布局的标签，这极大的提升了表单样式丰富度，但对B端系统交互界面统一带来了不小挑战：

1.对同一内容的表单，不同的设计师有不同的认知，导致同一功能UI界面不一致。

例如一个简单的用户信息录入界面，在布局上就会出现，纵向、横向、栅格等多种布局方案，同时表单按钮也有在页面底部固定、伴随页面滚动等方案：

2.样式修改成本低，研发工程师可以随意修改表单样式。

大部分公司前端资源相对紧张，一些简单的页面常常交由后端人员开发，开发过程中存在盲目复制代码、不按设计规范实现界面等问题，导致实际界面和UI设计规范相差甚远：

同时HTML本身是一门描述界面的语言，针对同一界面有不同的表达，更大程度加剧了上述两个问题，巨量UI走查工作让我们难以承受。

探索B端表单规范

针对上述问题，我们对自己提出一个大胆的设想：

能否设计一套体系，让产品和研发只关注业务本身，通过规约等方案实现代码和界面一一对应。

为了保证交互、视觉的一致性，我们尝试思考抛开UI、交互思考表单的本质到底是什么，反复问自己一个初级问题“表单是什么？”，为此我们认为在交互、UI下还有一层被称为“本质”设计，程序语言是用于描述本质本身，通过代码封装将交互、UI规则沉淀到组件内部，从而保证交互、视觉一致性。

表单域

表单域（表单元素）是表单信息录入最小单元，不同的表单域有着不同的交互方式，但无论文本框、下拉框还是单\复选框，剥离交互、UI来看，本质都是key-value的键值对，通过大量项目抽象佐证，我们认为一个基础表单域有4个核心属性：

label：当前表单元素“键”UI层描述

name：当前表单元素“键”编码逻辑层名称，用于编码逻辑

text：当前表单元素“值”UI层描述

value：当前表单元素“值”编码逻辑层具体值，用于编码逻辑

例如一个简单的性别选择组件，label是“性别”，name是“sex”，text是“男”，value是“1”

PS：这里用下拉组件简单举例，但在基于本质的设计中，select又是一个复杂的组件，它是input框+Button+Pop的组合，针对这块内容，我们后面有机会再详解。

通常text和value以当前元素输入（选中）值表达，文本输入框时我们可认为value及text，但在一些复杂情况下表单域的text和value可能存在不一致的情况，如

表单

有了表单域的概念，表单的本质就更好理解，表单是一个或多个表单域的组合，通常在UI库设计过程中，我们会更多思考表单的各种部件形态，但是在面向本质的UI库中，我们强制表单内部只能编写表单域，不能嵌套布局等其他标签，原因如下：

1.编码人员应该专注描述业务本身，而不是界面。

2.不同的交互、布局规则应该沉淀到系统本身，通过规约由组件自身判断，如水平、垂直、流式、栅格等布局方式。

3.B端设计大部分情况下布局几乎一致，一些特定场景我们可以通过自定义组件方式实现差异化效果。

通过对表单本质的抽象，我们设计了一门描述本质（或业务本身）的标记式语言DML（Dmall Markup Language），一个简单表单可简洁描述如下：

<form><item is="input" label="姓名" name="name"/><item is="num" label="年龄" name="age"/><item is="select" label="性别" data="..." name="sex"/></form>

而它的布局会在不同尺寸、不同使用场景下，由框架自动适配达到设计师想要的效果。

嵌套

上述文章描述了一个基本表单的定义过程，其实在挖掘表单本质过程中，我们深度思考了很多情况，如嵌套。嵌套是表单比较常见的场景，但对于同一嵌套样式，至少有3种认知：

1.有三个Form表单域，第一个有key，后面两个没有value。

2.有一个Form表单域，左侧是key，右侧是value，下面两个元素是第一个元素的子元素。

3.有一个Form表单域，左侧是Key，右侧整体是Value，整个Value是一个复杂的数据结构。

经过反复佐证，我们认为第3种认知能契合表单就是key-value的基本逻辑，同时让整个表单规则自洽。为了实现上文提到的UI和编码一一映射，我们针对不同方式编码在视觉层进行规则约束“表单域在没有label时，视觉会对齐父级元素基线”，如

所以在整个规则的抽象中，我们常常是大胆假设本质，然后通过交互、UI、代码不同层面反复论证，以求找到设计中的“真理”

结论

基于上述推论，我们尝试得出表单最基本的三条理论：

1.表单是多个表单域的组合，表单域是表单最小单元。

2.一个表单域本质是key-value的键值对，具备label、value、name、text四个基本属性。

3.表单域的“value”可能是个复杂结构，需要通过另一层复杂操作产生的数据。（这种复杂结构以后会展开分析）

基于这条理念设计的表单，目前已经在我们项目中大量使用。这种基于本质设计的组件，由于语言本身描述逻辑而非界面， 能轻易实现UI一致性及跨端等特性。目前我们能做到一套代码针对不同端特性做到真正意义上适配，而非简单的弹性布局适配。

预告一波：今年10月24日下午14:00-18:00，D+Talks 2021多点技术大会将拉开帷幕，我们将分享更多关于CabinX设计理念，欢迎有兴趣的同学识别下图二维码参加线下活动！