设计系统的工作流程
前端工具如何协同工作对设计和开发团队可以实现的最终价值具有重大影响。如果做得好，开发和重用 UI 组件应该是无缝的。
本章通过介绍一个新的组件 AvatarList 来展示五步工作流程。
构建
AvatarList 是一个显示多个头像的组件。与其他设计系统组件一样，AvatarList 最初被粘贴到许多项目中，这就是它值得包含在设计系统中的原因。让我们假设该组件是在另一个项目中开发的，并直接跳转到此演示的完成代码。
首先，创建一个新分支，我们将在其中跟踪这项工作。
git checkout -b create-avatar-list-component
下载 AvatarList 组件和 story 到您的机器上，并将它们放在 /src/AvatarList 目录中
💡 Storybook 被设置为自动检测以 *.stories.js|jsx 结尾的文件，并在 UI 中显示它们。
太棒了！现在让我们阐明 AvatarList 支持的每个 UI 状态。乍一看，很明显 AvatarList 支持 Avatar 的一些属性，例如 small 和 loading。
export const SmallSize = {
args: {
...Short.args,
size: 'small',
},
};
export const Loading = {
args: {
...Short.args,
loading: true,
},
};
鉴于它是一个列表，它应该显示许多头像。让我们添加一些 story，展示当列表项很多和列表项很少时会发生什么。
export const Ellipsized = {
args: {
users: [
...Short.args.users,
{
id: '3',
name: 'Zoltan Olah',
avatarUrl: 'https://avatars0.githubusercontent.com/u/81672',
},
{
id: '4',
name: 'Tim Hingston',
avatarUrl: 'https://avatars3.githubusercontent.com/u/1831709',
},
],
},
};
export const BigUserCount = {
args: {
users: Ellipsized.args.users,
userCount: 100,
},
};
export const Empty = {
args: {
users: [],
},
};
保存您的进度并提交。
git commit -am "Added AvatarList and stories"
文档
借助 Storybook 的 自动文档 功能，创建可自定义的文档非常轻松。这对于其他想要学习如何使用 AvatarList 的人来说很有益，因为他们可以轻松地参考 Storybook UI 中的文档条目。
最低限度的可行文档！让我们通过提供有关如何使用 AvatarList 的更多上下文，使其更人性化。
/**
* A list of Avatars, ellipsized to at most 3. Supports passing only a subset of the total user count.
*/
export function AvatarList({ loading, users, userCount, size, ...props }) {}
添加一些关于支持的 props 的额外细节。
AvatarList.propTypes = {
/**
* Are we loading avatar data from the network?
*/
loading: PropTypes.bool,
/**
* A (sub)-list of the users whose avatars we have data for. Note: only 3 will be displayed.
*/
users: PropTypes.arrayOf(
PropTypes.shape({
id: PropTypes.string.isRequired,
name: PropTypes.string,
avatarUrl: PropTypes.string,
})
),
/**
* The total number of users, if a subset is passed to `users`.
*/
userCount: PropTypes.number,
/**
* AvatarList comes in four sizes. In most cases, you’ll be fine with `medium`.
*/
size: PropTypes.oneOf(Object.keys(sizes)),
};
易如反掌！这种程度的细节现在就足够了——我们总是可以在以后使用 MDX 进行更多自定义。
文档不必令人厌烦。借助自动化工具，我们消除了乏味，直接开始编写。
提交更改并推送到 GitHub。
git commit -am "Improved AvatarList docs"
准备发布
在将我们的组件发布到设计系统之前，我们必须确保它在安装后可用。让我们将其添加到设计系统的 index.js 文件中。
import * as styles from './shared/styles';
import * as animation from './shared/animation';
import * as icons from './shared/icons';
import * as global from './shared/global';
export { styles, animation, icons, global };
export * from './Avatar';
+ export * from './AvatarList';
export * from './Badge';
export * from './Button';
export * from './Icon';
export * from './Link';
export * from './LinkWrapper';
创建 Pull Request
让我们将我们的 AvatarList 分支推送到 GitHub 并创建一个 pull request
git push -u origin create-avatar-list-component
然后导航到 GitHub 并打开一个 pull request。
审查
此时，AvatarList 是设计系统包含的候选对象。利益相关者必须审查该组件，以查看它是否满足对功能和外观的期望。
设计系统的 Storybook 会在每个 pull request 中自动发布，以使审查变得非常简单。向下滚动到 PR 检查以查找已部署 Storybook 的链接。
在您发布的 Storybook 中找到 AvatarList。它应该看起来与您的本地 Storybook 完全相同。
发布的 Storybook 是团队的通用参考点。与其他利益相关者共享 AvatarList 的链接，以更快地获得反馈。您的团队会喜欢您，因为他们不必处理代码或设置开发环境。
与众多团队达成共识通常感觉像是在做无用功。人们引用过时的代码，没有开发环境，或者将反馈分散在多个工具中。在线审查 Storybook 使其像共享 URL 一样简单。
测试
我们的测试套件在后台每次提交时运行。 AvatarList 是一个简单的展示组件，因此不需要单元测试。但是，如果我们查看 PR 检查，我们的可视化测试工具 Chromatic 已经检测到需要审查的更改。
由于 AvatarList 是新的，因此还没有针对它的可视化测试。我们需要为每个 story 添加基线。在 Chromatic 中接受“新 story”以扩展可视化测试覆盖率。
完成后，构建将在 Chromatic 中通过。
反过来，这会更新 GitHub 中的 PR 检查。
测试已成功更新。将来，回归将很难潜入设计系统。
分发
我们有一个打开的 pull request，它将 AvatarList 添加到设计系统中。我们已经编写了 story，测试通过了，并且文档也存在。最后，我们准备好使用 Auto 和 npm 更新我们的设计系统包。
将 minor 标签添加到 PR。这告诉 Auto 在合并时更新包的次要版本。
现在合并您的 PR，导航到 npm 上的包，并耐心等待几分钟，直到包更新。
成功！您的设计系统包已从 GitHub 的便利性中更新。无需接触命令行或摆弄 npm。更新示例应用中的 learnstorybook-design-system 依赖项以开始使用 AvatarList。
您的旅程开始了
面向开发者的设计系统 重点介绍了专业前端团队使用的端到端工作流程，为您在开发自己的系统时提供先发优势。随着设计系统的发展，添加、重新排列和扩展这些工具以适应您团队的需求。
第 9 章总结了完整的示例代码、有用的资源以及来自开发人员的常见问题。