React Spectrum Semantic Elements 机制解析基于上下文插槽的通用元素样式适配【免费下载链接】react-spectrumA collection of libraries and tools that help you build adaptive, accessible, and robust user experiences.项目地址: https://gitcode.com/GitHub_Trending/re/react-spectrum本文基于 React Spectrum 仓库中 2019 年 Semantic Elements RFC 展开讲清楚“同一个标题元素在 Card 和 Dialog 中如何自动获得不同样式”这一设计问题的完整解法从动机、失败的旧方案到上下文Context驱动的 CSS 与 React 实现草案并对照仓库中真正落地的 Slots 工具实现 与 布局文档说明这套机制是如何从一份设计提案演化为生产代码的。读完后你将掌握“语义元素 插槽上下文”这一模式的设计原理、API 形态及其在 React 组件库中的工程实现方式。一、RFC 背景通用元素为什么需要“上下文感知”的样式这份 RFC 于 2019-10-31 启动作者为 Rob Snow 与 Devon Govett是 React Spectrum v3 时期一组架构提案另见 Slots 架构 RFC、v3 架构 RFC中的一环。其 Summary 一句话概括了目标Common elements should be useable everywhere and should have the right styles on them for where they are used. 通用元素应该可以在任何地方使用并且应该拥有“在其使用位置上”的正确样式。动机同一种内容差异极大的样式仓库中大量组件都有 header/title、description、avatar、各类通用组件。这些部分在不同容器中的样式差异可能非常大——例如 Card 的标题和 Dialog 的标题语义上都是“标题”但字号、间距完全不同。RFC 列举了三种曾被尝试过的旧方案及其各自的缺陷这部分是理解本提案价值的关键为每种容器造专用子组件Dialog 配DialogHeader、DialogFooterCard 配CardHeader、CardFooter……结果是组件数量爆炸大量“功能相同、只是样式不同”的变体组件。用 CSS 模式匹配选择器匹配与 CSS Modules 配合不好如果使用元素选择器而非类名就无法预测组件实际会被用在哪里。Styled Components与 Spectrum CSS 的工作方式配合不好。这三种失败尝试共同指向一个结论需要一种“元素本身不变、由容器决定其样式”的机制。二、核心提案代表真实 DOM 节点的语义元素RFC 的 Proposal 部分给出的方案可以拆成三点创建代表真实 DOM 节点的元素Heading对应h1等标题标签、Section对应section、Avatar对应一种img、Preview对应另一种img。元素语义与 DOM 结构保持稳定只有样式随上下文变化。从上下文对象读取应应用的 className这些组件都会读取 context 对象从中取出自己应该应用的类名。容器组件Card、Dialog负责把“我期望子元素的样式”写进上下文。语义元素是 Slots 的子集RFC 明确指出Semantic Elements 可以视为 Slots RFC 的一个子集——因为可能有很多元素语义上都属于“description”。Slots 提供了更大的灵活性而语义元素的默认插槽名就是它自己的名字Heading的默认 slot 为heading。新旧两种组件模式的对比旧模式每种容器一套专用子组件// Card Card CardHeader / CardDescription / CardFooter / /Card // Dialog Dialog DialogHeader / DialogDescription / DialogFooter / /Dialog新模式复用同一组语义元素样式由容器上下文决定// Card Card Header / Description / Footer / /Card // Dialog Dialog Header / Description / Footer / /Dialog支持任意 DOM 结构RFC 还特别强调要支持任意 DOM 嵌套结构同时保持语义元素的样式正确。Card 会在上下文中提供类名即使Header被包在任意深度的div里类名依然会被应用Card div HeaderTitle/Header ButtonX/Button /div DescriptionDescription goes here/Description /Card这正是用 Context 而非 CSS 层级选择器做“容器到子元素样式传递”的根本原因React Context 天然穿透任意嵌套层级不受 DOM 结构约束。三、设计示例一套 JSX两种视觉RFC 要求设计团队能够给出两个语义子元素明显相似、但视觉呈现不同的组件设计。以 Dialog 和 Card 为例两者都有清晰的标题、正文和按钮标题字号不同Dialog 标题 18px、Card 标题 14px其余部分一致。上图中的 Dialog 与 Card 设计稿即来自 RFC 文档内嵌的设计示例图它们证明“同一组语义元素可以在不同容器中呈现正确的差异”。四、CSS 侧容器前缀类名 后代选择器RFC 给出的 CSS 示例展示了 Spectrum CSS 需要遵循的类名约定容器提供带自己前缀的“子元素类名”。Card 一侧adobe/spectrum-css/components/card/vars.css.spectrum-Card { border: 1px solid lightgrey; border-radius: 4px; background: white; } .spectrum-Card-title { font-size: 14px; }Dialog 一侧adobe/spectrum-css/components/dialog/vars.css.spectrum-Dialog { border: 1px solid lightgrey; border-radius: 4px; background: white; } .spectrum-Dialog-title { font-size: 18px; }两个文件共同点在于容器类.spectrum-Card/.spectrum-Dialog定义自身外观-title类只定义标题字号差异。React 组件把两者组合进最终 DOM 类名后标题就会分别拿到 14px 与 18px。RFC 同时声明了这里的限制只能接受“后代descendant”这一种通用匹配形态无法保证 direct child直接子元素或其他 DOM 结构模式匹配。这与 Context 方案一致——样式传递走 React 上下文不依赖 DOM 父子关系因此也天然放弃了 CSS 层级的选择器能力。对应的容器组件实现草案import styles from adobe/spectrum-css/components/card/vars.css; export const Card (props) { return ( div className{classNames(styles, spectrum-Card)} SlotContext.Provider value{{ title: classNames(styles, spectrum-Card-title) }} {props.children} /SlotContext.Provider /div ); };要点Card 自己引用自己的 CSS Module通过SlotContext.Provider下发“槽名 → className”的键值对。键是语义元素的名字值是应该应用到该语义元素上的类名。RFC 还提到一个未展开的细节容器组件应该允许外部覆盖override这份映射。五、React 侧语义元素实现草案语义元素从上下文取类名RFC 中Heading的草案实现如下核心是useSlotProvider()从上下文中取出名为heading的项并合并进自身 classNameexport const Heading (props) { let { heading } useSlotProvider(); return ( h1 className{classNames(styles, heading, props.className)} SlotContext.Provider value{{ avatar: null, heading: null, text: null, section: null, spacer: null, item: null }} {props.children} /SlotContext.Provider /h1 ); };注意className的合并顺序classNames(styles, heading, props.className)—— 语义元素自身的默认样式、上下文提供的样式、用户显式传入的className依次叠加用户覆盖优先级最高。“消费后清空”上下文的取舍RFC 提出一个值得注意的讨论点是否让语义元素在消费完上下文后将其清空以防止类名意外“渗透”trickle down到更深层级。作者的判断是这样做“可能有助于防止意外的向下传递但不能保证效果所以也许不是个好主意”。这一保留意见在落地实现中得到了呼应见下一节的ClearSlots。容器组件提供“槽名 → className”映射export const Card (props) { return ( div className{classNames(styles, spectrum-Card)} SlotContext.Provider value{{ heading: classNames(styles, heading), description: classNames(styles, description) }} {props.children} /SlotContext.Provider /div ); };模式总结容器组件引用自己的 CSS Module供给一组键值对键是语义元素的名字值是该元素应该应用的 className。六、仓库实现对照从 RFC 草案到 Slots 工具RFC 中的useSlotProvider/SlotContext.Provider在今天的代码库中演化为 packages/adobe/react-spectrum/src/utils/Slots.tsx 中的四个工具。逐一对照可以看清“提案 → 实现”的演化路径。1. SlotContext 与 useSlotProps语义元素的取样式入口let SlotContext React.createContext{} | null(null); export function useSlotPropsT(props: T {id?: string}, defaultSlot?: string): T { let slot (props as SlotProps).slot || defaultSlot; let {[slot]: slotProps {}} useContext(SlotContext) || {}; return mergeProps(props, mergeProps(slotProps, {id: props.id})) as T; }见 Slots.tsx 第 20–29 行。与 RFC 草案相比有三点演进默认插槽名成为显式参数defaultSlot参数直接落实了 RFC“语义元素的默认插槽名就是它自己的名字”的设计——Heading内部调用时传defaultSlotheading即可同时仍可通过slotprop 显式改道这是 Slots 的完整能力。上下文值从“className 字符串”升级为“props 对象”RFC 草案里上下文值只是一个类名字符串落地实现中每个槽位对应一组 props如{UNSAFE_className: ...}这与 Slots RFC 中“slot 可以传递 props”的思路一致例如 Dialog 头部与内容之间的 Divider 需要预设尺寸。组件自身的id永远优先mergeProps(slotProps, {id: props.id})保证组件自己的 id 不被插槽 props 覆盖这对 ARIA 关联至关重要。2. cssModuleToSlotsCSS Module 到槽位映射的快捷转换export function cssModuleToSlots(cssModule: {[cssmodule: string]: string}): { [slot: string]: {UNSAFE_className: string}; } { return Object.keys(cssModule).reduce((acc, slot) { acc[slot] {UNSAFE_className: cssModule[slot]}; return acc; }, {}); }见 Slots.tsx 第 31–38 行。RFC 草案中容器组件手工写出{heading: classNames(styles, heading), ...}落地实现则提供了这个转换函数把 CSS Module 对象整体映射为“槽名 →{UNSAFE_className}”的结构让容器组件的写法更接近 RFC 的意图且不易出错。3. SlotProvider上下文的层级合并export function SlotProvider(props: { slots?: {[slot: string]: object}; children?: ReactNode; }): ReactNode { const emptyObj useMemo(() ({}), []); let parentSlots useContext(SlotContext) || emptyObj; let {slots emptyObj, children} props; let value useMemo( () Object.keys(parentSlots) .concat(Object.keys(slots)) .reduce( (o, p) ({ ...o, [p]: mergeProps(parentSlots[p] || {}, slots[p] || {}) }), {} ), [parentSlots, slots] ); return SlotContext.Provider value{value}{children}/SlotContext.Provider; }见 Slots.tsx 第 40–65 行。注意它是合并而非替换父级上下文嵌套容器时父容器的槽位定义依然对子树可见父槽位在前、自身槽位在后参与mergeProps。这直接支撑了 RFC 中“即使嵌套类名仍然会被应用”的任意 DOM 结构示例。4. ClearSlots对“消费后清空”的最终回应export function ClearSlots(props: {children?: ReactNode}): ReactNode { let {children, ...otherProps} props; const emptyObj useMemo(() ({}), []); let content children; if (React.Children.toArray(children).length 1) { if (typeof children function) { content React.cloneElement(React.Children.only(children), otherProps); } } return SlotContext.Provider value{emptyObj}{content}/SlotContext.Provider; }见 Slots.tsx 第 67–80 行。RFC 对“语义元素消费后自动清空上下文”持保留态度从源码结构看最终方案没有让每个语义元素各自清空那会破坏“合并优先”的嵌套语义而是提供一个显式的ClearSlots组件由容器主动决定是否切断上下文向下传递——把“是否清空”的决策权交回给容器作者恰好绕开了 RFC 指出的“不能保证效果”的问题。5. 文档侧的落地形态官方布局文档 对这套机制的现行描述与 RFC 一脉相承“部分 React Spectrum 组件内置了预制布局你可以用插槽插入内容这通常通过语义元素自动发生也可以通过 props 配置。例如Dialog接受Heading、Content、Footer等子元素并自动处理布局。” 组件层面的设计规范则沉淀在 specs/api/Shared.md、specs/api/Card.md 等 API 规范文档中可供进一步查证各语义元素的行为约定。七、提案的落地前提What will this takeRFC 最后明确列出该方案生效所需的两个外部前提Buy in from Spectrum CSSSpectrum CSS 团队需要接受“容器前缀 子元素类名”.spectrum-Card-title的类名约定并保证各组件的 vars.css 按此形态组织。Buy in from Design设计团队需要能够以“语义区域 命名 slot”的方式交付线框图这一诉求在 Slots RFC 中进一步展开包括用 CSS Grid 的grid-template-areas实现“布局与 JSX 解耦”的设计稿。八、小结Semantic Elements 方案的核心可以概括为三层职责角色职责仓库证据语义元素Heading/Description/Footer 等保持稳定的 DOM 语义通过useSlotProps从上下文取样式Slots.tsx容器组件Card/Dialog 等通过SlotProvider下发“槽名 → props”映射允许外部覆盖Slots.tsxSpectrum CSS按spectrum-Card-title类约定提供差异化的子元素样式RFC 中的 CSS 示例由此RFC 中“Common elements should be useable everywhere and should have the right styles on them for where they are used”的目标得以实现消灭了CardHeader/DialogHeader式的组件变体爆炸样式差异从“组件数量”转移到“CSS 类名 上下文映射”这一低成本维度上。若你想继续深入容器如何把子元素摆到正确位置而不仅仅是“摆对样式”配套的 Slots 架构 RFC 与 v3 架构 RFC 是同一设计体系的自然延伸项目整体的 RFC 流程规则见 rfcs/README.md。【免费下载链接】react-spectrumA collection of libraries and tools that help you build adaptive, accessible, and robust user experiences.项目地址: https://gitcode.com/GitHub_Trending/re/react-spectrum创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 React Spectrum Semantic Elements 机制解析：基于上下文插槽的通用元素样式适配
React Spectrum Semantic Elements 机制解析基于上下文插槽的通用元素样式适配【免费下载链接】react-spectrumA collection of libraries and tools that help you build adaptive, accessible, and robust user experiences.项目地址: https://gitcode.com/GitHub_Trending/re/react-spectrum本文基于 React Spectrum 仓库中 2019 年 Semantic Elements RFC 展开讲清楚“同一个标题元素在 Card 和 Dialog 中如何自动获得不同样式”这一设计问题的完整解法从动机、失败的旧方案到上下文Context驱动的 CSS 与 React 实现草案并对照仓库中真正落地的 Slots 工具实现 与 布局文档说明这套机制是如何从一份设计提案演化为生产代码的。读完后你将掌握“语义元素 插槽上下文”这一模式的设计原理、API 形态及其在 React 组件库中的工程实现方式。一、RFC 背景通用元素为什么需要“上下文感知”的样式这份 RFC 于 2019-10-31 启动作者为 Rob Snow 与 Devon Govett是 React Spectrum v3 时期一组架构提案另见 Slots 架构 RFC、v3 架构 RFC中的一环。其 Summary 一句话概括了目标Common elements should be useable everywhere and should have the right styles on them for where they are used. 通用元素应该可以在任何地方使用并且应该拥有“在其使用位置上”的正确样式。动机同一种内容差异极大的样式仓库中大量组件都有 header/title、description、avatar、各类通用组件。这些部分在不同容器中的样式差异可能非常大——例如 Card 的标题和 Dialog 的标题语义上都是“标题”但字号、间距完全不同。RFC 列举了三种曾被尝试过的旧方案及其各自的缺陷这部分是理解本提案价值的关键为每种容器造专用子组件Dialog 配DialogHeader、DialogFooterCard 配CardHeader、CardFooter……结果是组件数量爆炸大量“功能相同、只是样式不同”的变体组件。用 CSS 模式匹配选择器匹配与 CSS Modules 配合不好如果使用元素选择器而非类名就无法预测组件实际会被用在哪里。Styled Components与 Spectrum CSS 的工作方式配合不好。这三种失败尝试共同指向一个结论需要一种“元素本身不变、由容器决定其样式”的机制。二、核心提案代表真实 DOM 节点的语义元素RFC 的 Proposal 部分给出的方案可以拆成三点创建代表真实 DOM 节点的元素Heading对应h1等标题标签、Section对应section、Avatar对应一种img、Preview对应另一种img。元素语义与 DOM 结构保持稳定只有样式随上下文变化。从上下文对象读取应应用的 className这些组件都会读取 context 对象从中取出自己应该应用的类名。容器组件Card、Dialog负责把“我期望子元素的样式”写进上下文。语义元素是 Slots 的子集RFC 明确指出Semantic Elements 可以视为 Slots RFC 的一个子集——因为可能有很多元素语义上都属于“description”。Slots 提供了更大的灵活性而语义元素的默认插槽名就是它自己的名字Heading的默认 slot 为heading。新旧两种组件模式的对比旧模式每种容器一套专用子组件// Card Card CardHeader / CardDescription / CardFooter / /Card // Dialog Dialog DialogHeader / DialogDescription / DialogFooter / /Dialog新模式复用同一组语义元素样式由容器上下文决定// Card Card Header / Description / Footer / /Card // Dialog Dialog Header / Description / Footer / /Dialog支持任意 DOM 结构RFC 还特别强调要支持任意 DOM 嵌套结构同时保持语义元素的样式正确。Card 会在上下文中提供类名即使Header被包在任意深度的div里类名依然会被应用Card div HeaderTitle/Header ButtonX/Button /div DescriptionDescription goes here/Description /Card这正是用 Context 而非 CSS 层级选择器做“容器到子元素样式传递”的根本原因React Context 天然穿透任意嵌套层级不受 DOM 结构约束。三、设计示例一套 JSX两种视觉RFC 要求设计团队能够给出两个语义子元素明显相似、但视觉呈现不同的组件设计。以 Dialog 和 Card 为例两者都有清晰的标题、正文和按钮标题字号不同Dialog 标题 18px、Card 标题 14px其余部分一致。上图中的 Dialog 与 Card 设计稿即来自 RFC 文档内嵌的设计示例图它们证明“同一组语义元素可以在不同容器中呈现正确的差异”。四、CSS 侧容器前缀类名 后代选择器RFC 给出的 CSS 示例展示了 Spectrum CSS 需要遵循的类名约定容器提供带自己前缀的“子元素类名”。Card 一侧adobe/spectrum-css/components/card/vars.css.spectrum-Card { border: 1px solid lightgrey; border-radius: 4px; background: white; } .spectrum-Card-title { font-size: 14px; }Dialog 一侧adobe/spectrum-css/components/dialog/vars.css.spectrum-Dialog { border: 1px solid lightgrey; border-radius: 4px; background: white; } .spectrum-Dialog-title { font-size: 18px; }两个文件共同点在于容器类.spectrum-Card/.spectrum-Dialog定义自身外观-title类只定义标题字号差异。React 组件把两者组合进最终 DOM 类名后标题就会分别拿到 14px 与 18px。RFC 同时声明了这里的限制只能接受“后代descendant”这一种通用匹配形态无法保证 direct child直接子元素或其他 DOM 结构模式匹配。这与 Context 方案一致——样式传递走 React 上下文不依赖 DOM 父子关系因此也天然放弃了 CSS 层级的选择器能力。对应的容器组件实现草案import styles from adobe/spectrum-css/components/card/vars.css; export const Card (props) { return ( div className{classNames(styles, spectrum-Card)} SlotContext.Provider value{{ title: classNames(styles, spectrum-Card-title) }} {props.children} /SlotContext.Provider /div ); };要点Card 自己引用自己的 CSS Module通过SlotContext.Provider下发“槽名 → className”的键值对。键是语义元素的名字值是应该应用到该语义元素上的类名。RFC 还提到一个未展开的细节容器组件应该允许外部覆盖override这份映射。五、React 侧语义元素实现草案语义元素从上下文取类名RFC 中Heading的草案实现如下核心是useSlotProvider()从上下文中取出名为heading的项并合并进自身 classNameexport const Heading (props) { let { heading } useSlotProvider(); return ( h1 className{classNames(styles, heading, props.className)} SlotContext.Provider value{{ avatar: null, heading: null, text: null, section: null, spacer: null, item: null }} {props.children} /SlotContext.Provider /h1 ); };注意className的合并顺序classNames(styles, heading, props.className)—— 语义元素自身的默认样式、上下文提供的样式、用户显式传入的className依次叠加用户覆盖优先级最高。“消费后清空”上下文的取舍RFC 提出一个值得注意的讨论点是否让语义元素在消费完上下文后将其清空以防止类名意外“渗透”trickle down到更深层级。作者的判断是这样做“可能有助于防止意外的向下传递但不能保证效果所以也许不是个好主意”。这一保留意见在落地实现中得到了呼应见下一节的ClearSlots。容器组件提供“槽名 → className”映射export const Card (props) { return ( div className{classNames(styles, spectrum-Card)} SlotContext.Provider value{{ heading: classNames(styles, heading), description: classNames(styles, description) }} {props.children} /SlotContext.Provider /div ); };模式总结容器组件引用自己的 CSS Module供给一组键值对键是语义元素的名字值是该元素应该应用的 className。六、仓库实现对照从 RFC 草案到 Slots 工具RFC 中的useSlotProvider/SlotContext.Provider在今天的代码库中演化为 packages/adobe/react-spectrum/src/utils/Slots.tsx 中的四个工具。逐一对照可以看清“提案 → 实现”的演化路径。1. SlotContext 与 useSlotProps语义元素的取样式入口let SlotContext React.createContext{} | null(null); export function useSlotPropsT(props: T {id?: string}, defaultSlot?: string): T { let slot (props as SlotProps).slot || defaultSlot; let {[slot]: slotProps {}} useContext(SlotContext) || {}; return mergeProps(props, mergeProps(slotProps, {id: props.id})) as T; }见 Slots.tsx 第 20–29 行。与 RFC 草案相比有三点演进默认插槽名成为显式参数defaultSlot参数直接落实了 RFC“语义元素的默认插槽名就是它自己的名字”的设计——Heading内部调用时传defaultSlotheading即可同时仍可通过slotprop 显式改道这是 Slots 的完整能力。上下文值从“className 字符串”升级为“props 对象”RFC 草案里上下文值只是一个类名字符串落地实现中每个槽位对应一组 props如{UNSAFE_className: ...}这与 Slots RFC 中“slot 可以传递 props”的思路一致例如 Dialog 头部与内容之间的 Divider 需要预设尺寸。组件自身的id永远优先mergeProps(slotProps, {id: props.id})保证组件自己的 id 不被插槽 props 覆盖这对 ARIA 关联至关重要。2. cssModuleToSlotsCSS Module 到槽位映射的快捷转换export function cssModuleToSlots(cssModule: {[cssmodule: string]: string}): { [slot: string]: {UNSAFE_className: string}; } { return Object.keys(cssModule).reduce((acc, slot) { acc[slot] {UNSAFE_className: cssModule[slot]}; return acc; }, {}); }见 Slots.tsx 第 31–38 行。RFC 草案中容器组件手工写出{heading: classNames(styles, heading), ...}落地实现则提供了这个转换函数把 CSS Module 对象整体映射为“槽名 →{UNSAFE_className}”的结构让容器组件的写法更接近 RFC 的意图且不易出错。3. SlotProvider上下文的层级合并export function SlotProvider(props: { slots?: {[slot: string]: object}; children?: ReactNode; }): ReactNode { const emptyObj useMemo(() ({}), []); let parentSlots useContext(SlotContext) || emptyObj; let {slots emptyObj, children} props; let value useMemo( () Object.keys(parentSlots) .concat(Object.keys(slots)) .reduce( (o, p) ({ ...o, [p]: mergeProps(parentSlots[p] || {}, slots[p] || {}) }), {} ), [parentSlots, slots] ); return SlotContext.Provider value{value}{children}/SlotContext.Provider; }见 Slots.tsx 第 40–65 行。注意它是合并而非替换父级上下文嵌套容器时父容器的槽位定义依然对子树可见父槽位在前、自身槽位在后参与mergeProps。这直接支撑了 RFC 中“即使嵌套类名仍然会被应用”的任意 DOM 结构示例。4. ClearSlots对“消费后清空”的最终回应export function ClearSlots(props: {children?: ReactNode}): ReactNode { let {children, ...otherProps} props; const emptyObj useMemo(() ({}), []); let content children; if (React.Children.toArray(children).length 1) { if (typeof children function) { content React.cloneElement(React.Children.only(children), otherProps); } } return SlotContext.Provider value{emptyObj}{content}/SlotContext.Provider; }见 Slots.tsx 第 67–80 行。RFC 对“语义元素消费后自动清空上下文”持保留态度从源码结构看最终方案没有让每个语义元素各自清空那会破坏“合并优先”的嵌套语义而是提供一个显式的ClearSlots组件由容器主动决定是否切断上下文向下传递——把“是否清空”的决策权交回给容器作者恰好绕开了 RFC 指出的“不能保证效果”的问题。5. 文档侧的落地形态官方布局文档 对这套机制的现行描述与 RFC 一脉相承“部分 React Spectrum 组件内置了预制布局你可以用插槽插入内容这通常通过语义元素自动发生也可以通过 props 配置。例如Dialog接受Heading、Content、Footer等子元素并自动处理布局。” 组件层面的设计规范则沉淀在 specs/api/Shared.md、specs/api/Card.md 等 API 规范文档中可供进一步查证各语义元素的行为约定。七、提案的落地前提What will this takeRFC 最后明确列出该方案生效所需的两个外部前提Buy in from Spectrum CSSSpectrum CSS 团队需要接受“容器前缀 子元素类名”.spectrum-Card-title的类名约定并保证各组件的 vars.css 按此形态组织。Buy in from Design设计团队需要能够以“语义区域 命名 slot”的方式交付线框图这一诉求在 Slots RFC 中进一步展开包括用 CSS Grid 的grid-template-areas实现“布局与 JSX 解耦”的设计稿。八、小结Semantic Elements 方案的核心可以概括为三层职责角色职责仓库证据语义元素Heading/Description/Footer 等保持稳定的 DOM 语义通过useSlotProps从上下文取样式Slots.tsx容器组件Card/Dialog 等通过SlotProvider下发“槽名 → props”映射允许外部覆盖Slots.tsxSpectrum CSS按spectrum-Card-title类约定提供差异化的子元素样式RFC 中的 CSS 示例由此RFC 中“Common elements should be useable everywhere and should have the right styles on them for where they are used”的目标得以实现消灭了CardHeader/DialogHeader式的组件变体爆炸样式差异从“组件数量”转移到“CSS 类名 上下文映射”这一低成本维度上。若你想继续深入容器如何把子元素摆到正确位置而不仅仅是“摆对样式”配套的 Slots 架构 RFC 与 v3 架构 RFC 是同一设计体系的自然延伸项目整体的 RFC 流程规则见 rfcs/README.md。【免费下载链接】react-spectrumA collection of libraries and tools that help you build adaptive, accessible, and robust user experiences.项目地址: https://gitcode.com/GitHub_Trending/re/react-spectrum创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考