logoAnt Design

⌘ K
  • 设计
  • 研发
  • 组件
  • 博客
  • 资源
  • 国内镜像
5.25.2
  • 👀 视觉回归测试
  • 为什么禁用日期这么难?
  • 封装 Form.Item 实现数组转对象
  • 行省略计算
  • 📢 v4 维护周期截止
  • antd 里常用的 TypeScript 工具方法
  • 一个构建的幽灵
  • 当 Ant Design 遇上 CSS 变量
  • API 的历史债务
  • 灵动的 Notification
  • 色彩模型与颜色选择器
  • 主题拓展
  • 虚拟表格来了!
  • 快乐工作主题(一)
  • 动态样式去哪儿了?
  • Suspense 引发的样式丢失问题
  • 打包体积优化
  • 你好,GitHub Actions
  • 所见即所得
  • 静态方法之痛
  • SSR 静态样式导出
  • 依赖排查
  • 贡献者开发维护指南
  • 转载-如何提交无法解答的问题
  • 新的 Tooltip 对齐方式
  • 非必要的渲染
  • 如何成长为 Collaborator
  • Modal hook 的有趣 BUG
  • antd 测试库迁移的那些事儿
  • Tree 的勾选传导
  • getContainer 的一些变化
  • 组件级别的 CSS-in-JS

所见即所得

相关资源

Ant Design X
Ant Design Charts
Ant Design Pro
Pro Components
Ant Design Mobile
Ant Design Mini
Ant Design Web3
Ant Design Landing-首页模板集
Scaffolds-脚手架市场
Umi-React 应用开发框架
dumi-组件/文档研发工具
qiankun-微前端框架
Ant Motion-设计动效
国内镜像站点 🇨🇳

社区

Awesome Ant Design
Medium
Twitter
yuque logoAnt Design 语雀专栏
Ant Design 知乎专栏
体验科技专栏
seeconf logoSEE Conf-蚂蚁体验科技大会
加入我们

帮助

GitHub
更新日志
常见问题
报告 Bug
议题
讨论区
StackOverflow
SegmentFault

Ant XTech logo更多产品

yuque logo语雀-构建你的数字花园
AntV logoAntV-数据可视化解决方案
Egg logoEgg-企业级 Node.js 框架
Kitchen logoKitchen-Sketch 工具集
Galacean logoGalacean-互动图形解决方案
xtech logo蚂蚁体验科技
主题编辑器
Made with ❤ by
蚂蚁集团和 Ant Design 开源社区

在日常开发过程中,你是否思考过一个问题。那就是范围限定和实际值不同的时候,应该如何去处理?假设我们有一个展示组件,它很简单的将你的值进行展示:

tsx
interface StrProps {
value: string;
}
function MyStr({ value }: StrProps) {
return <div>{value}</div>;
}
<MyStr value="Hello World" />;

毫无疑问,页面上就该展示 Hello World。接着,我们加个范围限定:

tsx
interface StrProps {
value: string;
maxLen?: number;
}

这个时候如果我们使用了超出范围的值应该显示什么?

tsx
<MyStr value="Hello World" maxLen={5}>

“显而易见”,既然有了 maxLen,那么就应该显示 Hello 而非 Hello World。

但是这种直觉的处理方式,却并不是所有情况下都是正确的。如果你使用原生的 input,你就发现表现并不是这样的:

tsx
<input value="Hello World" maxLength={5} />
input limit

按照标准描述,maxLength 只限制用户输入。这是标准错了吗?

A form control maxlength attribute, controlled by the dirty value flag, declares a limit on the number of characters a user can input.

“多此一举”

带着上面的疑问,我们想象一个输入场景。现在你有一个电商系统,给商品设定价格:

tsx
<Form>
<Form.Item label="Name" name="name">
<Input />
</Form.Item>
<Form.Item label="Price" name="price">
<InputNumber />
</Form.Item>
</Form>
Form

某天你的经理说,我们的商品价格按规定不能超过 99 元,你要直接在表单上做限制。这个改动并不难:

diff
-- <InputNumber />
++ <InputNumber max={99} />

但是对于现有的商品,我们显然不能直接在表单上做限制。否则,用户在编辑商品的时候,就会发现自己的商品价格被改了。这显然是不合理的。

Form modify

(用户永远无法明白为什么后台的数据和看到的对不上了)

实际上在很多场景下,组件都不应该直接修改实际值。尤其是输入型组件,擅自更改展示值会出现非常严重的后果。

所见即所得

在组件库层面,我们不能“推测”用户的使用场景,因而需要以最保守的方式实现边界场景的处理。但是同时我们其实可以做一些优化手段。比如说将限制设置到 Form.Item 的 rules 上,利用表单校验能力来做限制:

Form rules

对于一些组件本身,也可以添加显式的样式提醒:

InputNumber

对于非输入型自定义组件,也可以考虑通过设计来提醒用户。比如说我们可以在展示组件上添加一个 Tooltip:

tsx
// Same demo we've seen before
<MyStr value="Hello World" maxLen={5}>
Customize

或者使用一些其他的展示方式:

Ellipsis

总结

在进行组件研发时,需要慎重处理边界场景。在大型项目中,上游使用者可能并不知道你的内部逻辑是如何处理的。因而随着复杂度以及使用场景的增加,我们更加推荐对于默认行为总是选择保守的处理方式。而对于不满足需求的情况,可以通过 HOC 的形式或者是一些额外的 Props 配置来实现,以防止开发者在使用时有过多的约定而不知。