在可切换主题的UI组件库中新建或修改组件

## 找出组件变更涉及的文件 以谨慎的贡献者身份参与可复用、可配置主题且具备无障碍能力的组件库。编辑前，先确定请求的行为、受影响的组件或实用工具，以及所有直接相关的层面。 请以仓库的实际结构为准，同时应预期一次组件变更可能涉及以下部分领域： - 运行时组件和组合式函数。 - 公共类型和导出项。 - 主题配方、变体和默认值。 - 单元测试、渲染测试、快照测试和无障碍测试。 - 用户文档和示例。 - 本地演练场或演示页面。 不要假设所有领域都必须变更。追踪现有组件及与其最接近的类似实现，然后只列出请求所需的变更范围。将源代码和测试规范限定在相应目录内；不要不加区分地将其应用于文档、示例或工具。 除非任务明确要求改变，否则应保留现有的公共行为。将属性转发、默认值解析、无障碍语义、从右到左的行为以及已记录的API视为契约，而不是实现细节。 ## 只读本次变更需要的指南，并用生成器起步 先阅读仓库级贡献指南，再只加载与任务相关的参考资料。例如，关于props、slots、events和模板模式，应使用组件结构指南；关于slots和variants，应使用主题指南；关于渲染、快照和无障碍，应使用测试指南；关于示例和标记，应使用文档指南。 不要仅仅因为某份参考资料存在就全部加载。先从受影响的文件入手，查看近期可比较的实现，只有在变更触及相应问题时才打开其他指南。 使用项目声明的包脚本和受支持的包管理器。安装依赖项后，在启动演练场、文档站点或检查之前，先运行所有必需的准备步骤或类型生成步骤。为变更选择合适的本地环境：主应用程序演练场、其他框架的演练场、专门的复现环境或文档站点。 创建组件时，优先使用仓库批准的生成器。编辑前先审查生成的文件，并且只请求任务所需的模板。如果没有适用的生成器，则手动复现既定的文件布局和命名规范。 ## 保持主题默认值的优先顺序和从右到左布局 始终遵循库中已经确立的代码规范： - 当工具链或样式指南要求时，将仅用于类型的导入项分开。 - 通过标准辅助工具定义运行时props的默认值，并在面向类型的API中记录公共默认值。 - 为渲染的元素添加稳定的slot标记。在根元素上，调用方提供的标记必须覆盖组件的回退值；内部元素则保留各自的标记。 - 禁用属性自动透传时，应调整或解析根绑定的顺序，避免调用方属性被静默覆盖。 - 通过标准计算机制构建响应式主题输出，而不是只计算一次主题状态。 - 按照完整的优先级链解析默认值：显式组件输入、最近的组或字段上下文、库级主题覆盖、组件默认值，最后是项目定义的应用程序配置。 - 如果代理处理会改变注入优先级，请向上下文辅助工具传递原始输入。如果不存在更近的上下文，应回退到已解析的组件值，而不是丢弃主题级默认值。 - 通过项目中支持代理的适配器转发基础库的props和events，以保留已解析的默认值。 使用语义化设计令牌，而不是原始调色板值。使用逻辑间距、位置、边框、圆角和文本对齐属性，确保布局在从左到右和从右到左的上下文中都能正常工作。当逻辑属性无法表达转换、光标、渐变或过渡的行为时，添加明确感知方向的替代方案。 使实现与现有模式保持一致。不要为了单个组件引入一套相互竞争的默认值系统、props转发路径或主题解析层。 ## 按清单完成从主题到测试和文档的组件实现 使用以下检查清单追踪新组件或重大组件功能： 1. 在标准运行时位置生成组件脚手架或创建组件。 2. 实现行为、公共props、slots、events和无障碍语义。 3. 添加或更新主题配方，包括slots、variants、复合variants和语义化令牌。 4. 导出公共类型，并注册主题系统所需的组件默认值接口。 5. 根据适用情况，为行为、props、slots、属性转发、方向性和无障碍能力添加有针对性的测试。 6. 更新用户文档，包含用法、示例和API详情。 7. 添加或更新用于展示变更后行为的演练场示例。 8. 运行代码检查、静态类型检查和相关测试套件。 只有当项目将快照视为有用的契约时才使用快照，并审查生成的变更，而不是自动接受它们。测试应聚焦于对外部有意义的行为和已知的优先级规则。 如果文档先于软件包发布部署，请保留项目批准的预发布标记，并将其放在受影响的标题或示例上。该标记有意说明已合并的文档可能描述将在下一次发布中推出的功能；在检查发布政策之前，不要移除该标记，也不要将其报告为不一致。 ## 实际运行lint和测试，附上结果提交拉取请求 将最终diff与最接近的既定模式和原始请求进行对照审查。确认： - 组件结构、公共类型和导出项保持一致。 - 主题代码使用语义化令牌，并保留完整的默认值优先级链。 - 根属性和slot标记尊重调用方的覆盖值。 - 逻辑属性或明确的方向变体覆盖从右到左的行为。 - 测试覆盖已变更的props、slots、行为和无障碍要求。 - 文档包含必要的用法、示例和API变更。 - 有意保留的预发布文档标记仍然完好。 运行仓库的代码检查、类型检查和相关测试命令，并报告实际结果。不要仅凭查看代码就声称检查通过。公共行为发生变化时，应更新文档。 使用仓库规定的提交消息规范和拉取请求模板。链接相关工作项，说明变更类型，描述行为和验证情况，并且只勾选有证据支持的检查清单项。 不要仅仅为了整洁而重写、`rebase`、`force-push`或压缩贡献者的提交历史。如果仓库采用squash合并，则可能允许保留多个开发提交；请遵循仓库的实际合并政策和用户授权。