作者：Dominik
- #1: Designing Design Systems
- #2: Tooltip Components Should Not Exist
- #3: Building Type-Safe Compound Components
我不是设计师。说实话，像素级完美的工作和任何涉及CSS的内容都不太是我的强项。我几乎不会打开Figma，偶尔打开时也只是乱点乱戳，祈祷能凑合用。😅
我的职业生涯始于后端工程师，使用基于JVM的语言（Java、Scala、Groovy），后来转向全栈React开发，最终落脚于前端后端交界处——这或许能用我过去五年维护TanStack Query（一个无头库）的事实来解释。
那么，为何如今我会在Sentry的设计工程团队工作，负责构建全新的Scraps设计系统呢？
设计工程
总体而言，我认为这类团队成员需要具备不同的技能。我们拥有出色的设计工程师，比如Nate Moore——在打造流畅、统一且极具美感的界面方面，他堪称势不可挡的力量。
但我们同样需要专注于API设计、性能优化、开发者体验、基础设施等环节的成员，正是这些环节保障了系统高效运转。设计体系远不止于美观组件的集合——它是其他团队快速高效交付一致化产品的关键入口。
正是这种技能组合让团队得以高效运转。虽然我绝非打造完美渐变或CSS过渡效果的专家，但能在其他领域贡献力量，确保系统保持稳健、可维护且易于使用。
此外，我们团队的职责远不止维护设计系统。我们的实际目标很简单：
代码库经过十余年的有机发展，其中许多部分运行良好，但仍有大量内容需要改进。我们正处于优化代码库的有利位置。完善的設計系統是实现目标的工具之一，但开发者培训、高效的持续集成管道以及不阻碍开发的项目结构同样至关重要。
从这个角度看，我认为自己同样肩负着开发者体验工程师的职责。设计系统固然重要——尤其在于它能加速团队协作——但它只是整体解决方案中的一环。任何阻碍效率的环节，我们都致力于简化、自动化或彻底消除。
优秀设计系统的核心要素
话虽如此，我近期深入思考了优秀设计系统的构成要素，发现单篇博文难以承载所有见解。因此决定以散文形式罗列灵感，未来将针对部分主题撰写深度解析。
若您对以下任一要点感兴趣，欢迎在评论区留言，我将优先展开阐述：
设计系统原则
- 允许属性，但数量不宜过多。避免布尔值。
- 拥抱类型安全。
- 真的，要比这更注重类型安全。
- 对无法在类型层面强制执行的内容进行代码检查。
- 务实行事，允许逃生通道，但不要泄露内部实现。
- 优先采用组合模式。
- 复合组件很棒，但必须类型安全。
- 约束机制有益，但需平衡且有意识地使用。
- 一致性至关重要，既包括视觉呈现也涵盖组件API。
- 文档固然重要，但类型定义更为关键。
- 顺带一提，务必使用jsdoc！
- 无障碍功能应内置而非附加。
- 明确使用场景，针对性构建方案。
- 气泡提示组件应予废弃。
- 先设计设计令牌，后构建组件。
- 性能优化不可或缺。
- 建立模式体系，而非仅依赖基础组件。
- 优化目标定为90%而非100%。
- 尽可能采用无头架构。
- 技术采用取决于文化而非技术本身。
- 交付代码转换工具。
- 欢迎外部贡献，并提供完善指南。
- 每项功能只保留一种实现方式，避免冗余，杜绝重复代码。
- 通过提供者注入行为。
- 明智选择默认值，坚持立场。
- 对关键功能进行视觉回归测试。
- 状态同步是万恶之源。
- 优先采用受控组件，必要时使用非受控组件，并确保类型化。
data-test-id是无障碍设计的隐患。- 为 React 的未来而构建。
