重复

• 我已搜索现有的问题

最新版本

• 我已测试了最新版本

摘要 💡

MUI 标签组件的目标是自动指示活动标签，并使活动标签与显示在该标签下的相关内容保持同步。而 Stepper 组件则有一个类似的目标，但稍微复杂一些：自动指示活动步骤、已完成的步骤和待处理的步骤。同时，理想情况下，可以以编程方式显示与该步骤相关的内容。
Stepper 具有 Tabs 不具备的一些额外功能和选项，但就像 Tabs 提供了一个既可以单独使用也可以与路由库集成的 API 一样，我们可以通过依赖于简单地体现组件状态的 props,以及通过内部驱动或覆盖这些 props 来设计 Stepper,使其额外的功能既灵活又可编程。
同样，Stepper 可以像 TabPanel 组件一样使用可选的 StepPanel 组件，它们与 TabPanel 组件的状态同步。目前我们还没有这些组件，但它们的行为应该几乎完全符合 TabPanel 的行为，唯一的区别在于 TabPanel 只有 active 和 inactive 状态时，StepPanel 需要三个状态：active、completed 和 pending,以体现当前步骤之前或之后的步骤。
最简单的方法似乎是利用来自 Tabs 组件的代码和模式，这样 MUI 就可以在所有组件组合中提供熟悉的、可预测的用户体验。因此，行为应基于“value” prop:即 Stepper 上的 value prop 定义组的状态，其中哪个步骤是“活动”的。然而，与其像 Tabs 上手动定义 value props 以匹配一样，我们将从 Stepper 的 children 数组中推断出它，因为 Stepper 本质上是一个顺序界面，由数字值驱动。
然后，Stepper 将通过以下几个额外属性进行增强：

• activeVariant 仅定义我们应用于当前活动 Step(与 Stepper 的“value”相对应的步骤)的 MUI 全局变体；
• completedVariant 然后定义我们如何对待已经完成的步骤(具有比当前 Stepper 的 value 更小的 Step value);
• pendingVariant 将定义我们如何对待尚未达到的步骤(具有比当前 Stepper 的 value 更大的 Step value )。

明确提供这些变体可能是可选的，因为我们可以声明 activeVariant 默认为 solid、completedVariant 默认为 soft、以及 pendingVariant 默认为 outlined;这提供了一个相当常规的“合理默认值”，同时允许自定义。除此之外，用户还可以利用其他标准的 MUI 样式模式覆盖这些变体(如果他们选择这样做的话)。
这是一种建设性的方法吗？我们是否愿意接受一个实现这种方法的 PR?

示例

• Tabs API,强调使用 value 以及如何根据 Mui-selected 类进行样式设置
• Global Variants,我们将其用作 active、pending、和 completed 步骤的默认样式

动机

提供基本的自动化/接线模式不仅能为每个组件的用户节省精力，还能帮助人们建立更持久的使用模式。具体来说，指示器样式与活动步骤状态之间的关联是一个我们现在还不支持的需求。此外，它还提供了在 MUI 产品组合中提供更高程度自动化的标准体验，特别是在比较 Stepper 和 Tabs 时。最后，通过以受支持的方式提供这种自动化，我们可以帮助避免人们在尝试自己添加此自动化时遇到的陷阱。例如，如果尝试编写一个 Package Step 的组件，最终会在最后一个指示器后出现额外的分隔线，因为它破坏了插入定义最后一个子元素的 data- 属性... 我们希望通过以一种明确的方式支持这种共同需求来帮助人们避免这种情况。