Semi-Design时间范围选择器的交互设计思考

背景介绍

Semi-Design作为抖音前端团队开发的企业级UI组件库，其TimePicker组件的时间范围选择功能(type="timeRange")在用户交互方面引发了一些讨论。核心问题在于：当用户选择的结束时间早于开始时间时，组件应如何处理这种看似"不合理"的情况。

问题本质

时间范围选择器面临一个基本矛盾：在仅显示时间(不包含日期)的情况下，无法判断用户是否真的需要选择跨天的时间段(如23:00到次日01:00)。这使得简单的自动调整策略可能适得其反。

设计考量

Semi-Design团队经过内部讨论后，决定保持当前的中立策略，主要基于以下考虑：

1. 跨天场景的普遍性：在实际业务中，跨天时间选择并非小众需求，而是相当常见的使用场景
2. 避免隐性限制：自动调整或禁用时间选项会在用户不知情的情况下施加限制，导致困惑
3. 一致性原则：组件行为应当明确且一致，不应有隐藏的"魔法"逻辑

替代解决方案

虽然Semi-Design核心组件不内置自动处理逻辑，但开发者可以通过以下方式实现类似效果：

1. 表单验证方案

利用Form组件的验证功能，在用户完成选择后给出明确提示：

<Form.TimePicker
  field='time'
  type='timeRange'
  validate={(val) => {
    if (val && val.length === 2 && val[0] >= val[1]) {
      return '开始时间不能晚于结束时间';
    }
  }}
/>

2. 受控组件方案

通过onChange事件和受控value属性，开发者可以自主决定如何处理时间顺序：

const [timeRange, setTimeRange] = useState([]);

const handleChange = (value) => {
  if (value.length === 2 && value[0] > value[1]) {
    // 自动交换顺序
    setTimeRange([value[1], value[0]]);
    // 或者保持原样并显示提示
  } else {
    setTimeRange(value);
  }
};

3. 禁用时间选项

对于确实不需要跨天选择的场景，可以动态禁用部分时间选项：

const disabledHours = (startHour) => {
  // 根据开始时间禁用早于开始时间的小时
  return Array.from({length: startHour}, (_, i) => i);
};

最佳实践建议

1. 明确业务需求：首先确认应用场景是否真的不需要跨天时间选择
2. 显式提示优于隐式调整：通过清晰的错误提示比自动调整更能让用户理解系统行为
3. 考虑使用DateTimePicker：如果需要完整的时间范围选择，考虑使用包含日期的DateTimeRangePicker组件

总结

Semi-Design在TimeRange选择器上的设计决策体现了对复杂业务场景的考量。虽然表面上看似乎缺少"智能"处理，但这种保守策略实际上提供了更大的灵活性和可控性，让开发者能够根据具体业务需求实现最适合的交互方案。理解这一设计哲学，开发者可以更好地利用组件构建符合业务需求的用户界面。