命名选项列表类型组件Props的最佳实践——以Button多变体为例

这确实是组件开发里很常见的一个纠结点，我来结合实际项目经验和工具支持情况给你拆解下这三种方案：

1. 字符串枚举形式（variant: PropTypes.oneOf(['primary', 'secondary'])） #

这是社区最主流的写法，优势很突出：

• 语义清晰，一眼就能看出这是控制组件变体的单一属性，不会出现多个布尔值同时为true的冲突情况
• 扩展性极强，后续加新变体（比如danger、outline）只需要在数组里新增值就行，不用额外加新Props
• 代码更简洁，能有效减少组件的Props数量

你提到的WebStorm自动补全问题确实存在，但其实有解决办法：
如果项目能迁移到TypeScript，直接定义一个联合类型就能完美解决：

type ButtonVariant = 'primary' | 'secondary';

interface ButtonProps {
  variant?: ButtonVariant;
}

不管是WebStorm还是VS Code都会自动补全合法的变体值，还能在编译阶段就校验传入值的合法性，比PropTypes的运行时校验更可靠。

如果还在使用PropTypes，也可以把枚举值抽成常量：

const BUTTON_VARIANTS = ['primary', 'secondary'];

Button.propTypes = {
  variant: PropTypes.oneOf(BUTTON_VARIANTS)
};

虽然没法直接触发补全，但能避免手写字符串出错，也方便统一维护所有变体值。

2. 独立布尔值形式（isPrimary: PropTypes.bool, isSecondary: PropTypes.bool） #

这种写法的优点是直观，传入isPrimary={true}就能明确知道要渲染主按钮，但缺点也很致命：

• 容易出现逻辑冲突：如果同时传入isPrimary={true}和isSecondary={true}，组件逻辑里得额外处理这种矛盾情况，增加复杂度
• 扩展性极差：每加一个新变体就得新增一个布尔Props，时间久了组件Props会变得冗余杂乱
• 语义模糊：变体多了之后（比如isDanger、isOutline），很难一眼看出这些Props都是用来控制同一种状态的

3. 带前缀的独立布尔值形式（variantPrimary: PropTypes.bool, variantSecondary: PropTypes.bool） #

这种写法比第二种稍好一点，通过variant前缀把相关Props归组了，可读性有所提升，但本质上还是没解决第二种方案的核心问题：

• 依然存在多Props同时为true的冲突风险
• 新增变体还是要加新Props，长期维护下来Props会越来越臃肿
• 代码量比字符串枚举形式多很多，不够简洁

总结建议 #

如果可以的话，优先选择字符串枚举形式+TypeScript，既保留了语义清晰、扩展性好的优势，又能完美解决IDE自动补全的问题。如果暂时没法迁移到TS，就把枚举值抽成常量，减少手写错误的概率。

只有在变体极少（比如只有两种，且永远不会新增）的极端场景下，才考虑用布尔值形式，但一定要在组件逻辑里加校验，防止同时传入多个true的情况。

内容的提问来源于stack exchange，提问作者Luka