2021 BREAKING CHANGES
props.durationInMS -> props.duration
FAQ
为什么显示时长小于默认值会被自动修正为默认值
显示时长其实有两个基础值，在我们的设计中（目前的），这两个值恰好是一个同一个数
- 默认值，代表了一般情景下最通用有效的显示时间
- 最小值，代表了满足"信息反馈传达给用户"需求所需要的最小时间
关于"最小有效时间"
- toast 的交互作用是"将信息反馈传达给用户"
- 所谓有效，简单来说，最起码得"用户可以将信息读完"
- 满足这个需要，需要考虑用户的注意力吸引、反应时间、阅读时间、...
- 我们可以简单推导出，toast 总是需要一个"最小停留时间"的
- 可以极限点举例，0.3 秒人眼足够觉察发现画面上的变化，但一般难以阅读完上面的信息，那么这样 0.3 秒依然是一个无效的停留时间
- 至于当前这个最小值 N 定的是否足够合理、通用，这个确实是可以商榷的（备注：更早期是 默认 3 sec，最小 2 sec）
- 默认值、最小值的指定，是设计层面敲定的
- 需要有所依据（用户研究之类的），而不是主观的"我觉得..."
- 设计经验，也是一种依据，但立场上，"基于经验"是设计上的权责，而开发则没有这个权责
关于组件在开发层面限制"自定义"自由度的意义
- 从上面的陈述，我们可以知道"最小值"是一个
设计规范 上定义的值，是具备约束意义的
- 组件库作为规范的落地（实现），理应将这种"约束"在体现为实际的生产约束
- 规范是设计人员、开发人员的共同线索，同受其约束而不是为"为所欲为"
- 如此才可向 "最佳实践" 收敛，更高效满足的一般需求，是规范、组件库的意义
假设一个具体的情景例子体会一下
- "toast 的停留时间不能小于 3 sec，否则无法满足用户的基本阅读需求" 这是目前的一个设计结论（这也是目前的实际情况）
- 此结论作为"最佳实践"沉淀到了规范中，并在组件实现中进行了相应的约束（这也是目前的实际情况）
- 遵循规范、使用组件库的项目中希望其停留时间设计为 1 sec
- 且不论是这个设计正确与否（主观的或者基于特殊情景需要的），实际情况就是"这与目前的最佳实践"不符
- 这种情况我们希望是可以被发现并确认的（由于组件上进行了限制，无法实现故可以被发现）
- 无论结果如何，都是有积极意义的
- 这个改动是不对的，那么及时修正回去，避免了"反交互体验"
- 这个改动是有意义，那么目前定的 3 sec 不是最佳实践（起码有了新的情况），我们要重新考虑（我们又更向"最佳实践"逼近了）
- 反过来，组件实现上不做相应的限制，那么规范中关于"最小停留时间"的设计约束，就完全靠"人"去执行
- 有意的（比如按个人偏好）、无意的（比如不知道此项约束的存在）抛开规范的情况一旦发生
- 要么就是无法发现，结果就是"反交互体验"
- 要么就是要每一次都要重新确认，这是经验无法沉淀带来的沟通成本
- 如果无法产生实际的约束作用，那么"为所欲为"仍是不可控的，这是违背规范、组件库初衷的
Learn More: Brick toast duration 的最小 default 背后的思考
