全栈开发者的 Storybook

全栈开发者负责从编写 CSS 到连接数据库的所有工作。这涉及大量的上下文切换和处理来自技术栈不同部分的副作用，最终可能会拖慢你的速度。

Storybook 帮助开发者专注于技术栈的 UI 层。它与你的应用并行运行，提供一个沙箱环境，用于隔离地可视化、开发和测试 UI 组件。这样你就可以更快地开发 UI，而无需启动整个应用、其服务或调试不稳定的第三方 API。

本文将分享如何使用 Storybook 来简化你的应用开发工作流。

编写 stories（故事）以减少重复性工作

组件在不同的应用状态下看起来不同。你浪费大量时间来为本地数据库 seeding、在代码中添加临时数据，或者只是四处点击以使应用处于正确状态，以便验证 UI 是否正确。

Storybook 则允许你将所有这些组件变体捕获为 stories（故事），并在你处理组件时随时重新访问它们——从而减少那些重复性的繁重工作。

工作原理

组件的超能力在于，你不需要启动整个应用就能看到它们如何渲染。你可以通过传入 props 来隔离地渲染特定变体。这就是一个 story（故事）。

考虑这个 RestaurantCard 组件。它有四种状态以及浅色和深色变体。你可以在 RestaurantCard.stories.tsx 文件中为所有这些情况编写 stories（故事）。这个文件会被提交到你的代码仓库，并可供整个团队使用。

在处理组件时，打开 Storybook，修改你的代码，并快速切换 stories（故事）以验证其外观和行为。

使用 Storybook 插件来模拟上下文和 API

Stories（故事）展示了 UI 元素的各种状态——从原子组件到页面。隔离组件可以更容易地验证它们的所有变体，即使是难以触及的边缘情况，例如加载和错误状态。

当你在应用树中向上移动时，复制所有 UI 变体会变得更加困难，因为组件连接到状态和后端 API。Storybook 使你能够模拟此类依赖关系。

🔌 数据提供者

Redux 和 Pinia 等状态管理库通过 context 或 composition API 向组件提供数据。你可以使用 Storybook 装饰器来模拟此类数据提供者。

📡 API 请求

对于消费来自 REST 或 GraphQL 端点数据的组件，可以使用Mock Service Worker 插件来模拟 API 请求。还有针对特定库的插件，例如Apollo、URQL、GraphQL Kit、Axios 等。

将设计工具与 Storybook 连接以实现顺畅交接

设计师将图像、规范和原型“交接”给开发者进行实现。这要求开发者在设计工具和代码编辑器之间跳跃，同时处理多个规范版本。这是一个繁琐且容易出错的过程。设计细节经常丢失，导致大量的来回沟通和返工。

交接插件可以将设计制品嵌入到 stories（故事）旁边，从而更容易地交叉引用规范和已编码的 UI。此外，这种连接将对团队的其他成员持续有效。

例如，Storybook Design 插件使你能够将 Figma 文件嵌入到插件面板中。

你可以将 Figma 文件附加到组件甚至单个 stories（故事）上。

// RestaurantCard.stories.tsx

export default {
 title: 'Components/RestaurantCard',
 component: RestaurantCard,
 parameters: {
   design: {
     type: 'figspec',
     url: 'https://www.figma.com/file/3Q1HTCalD0lJnNvcMoEw1x/Mealdrop?node-id=1126%3A3893',
   },
 },
} as ComponentMeta<typeof RestaurantCard>;

不使用 Figma？还有针对 Zeplin、Zeroheight、UXPin、InVision DSM、Adobe XD、Sketch 等的类似可用插件。

使用插件将 Storybook 嵌入到 Figma 中

你可以使用Storybook Connect 插件进一步加快交接速度，该插件将 stories（故事）链接到 Figma 组件变体。它通过在 Figma 文件中嵌入实时 stories（故事）来实现。

在审查设计时，你可以通过点击 Figma 侧边栏中的链接来查看连接的 story（故事）。或者点击“在浏览器中打开 story”进入 Storybook 环境，其中包含插件、测试和 API 文档。

使用 stories（故事）为测试提供支持并捕获回归问题

测试帮助我们自信地发布代码。它们可以捕获回归问题和应用行为的意外更改。无论你采用何种方法，前端应用测试最终都归结为测试组件。

要测试一个组件，你必须隔离地渲染它并提供模拟数据来设置场景——这就是一个 story（故事）。因此，你可以使用 stories（故事）作为测试用例来加快编写测试的速度并减少维护负担。让我们看一个例子。

在这个 RestaurantDetailPage 页面上，用户可以从菜单中选择一个项目将其添加到购物车。为了测试此功能，我们将初始状态描述为一个 story（故事）。然后将一个play function 附加到该 story（故事），以模拟用户行为（例如点击和输入）并运行断言。最后，Storybook 将在浏览器中执行此测试。

// RestaurantDetailPage.stories.tsx

import { ComponentStory, ComponentMeta } from '@storybook/react';
import { rest } from 'msw';
import { expect } from '@storybook/jest';
import { within, userEvent } from '@storybook/testing-library';
import { BASE_URL } from '../../api';
import { restaurants } from '../../stub/restaurants';
import { RestaurantDetailPage } from './RestaurantDetailPage';
 
export default {
 title: 'Pages/RestaurantDetailPage',
 component: RestaurantDetailPage,
} as ComponentMeta<typeof RestaurantDetailPage>;
 
export const WithModalOpen: ComponentStory<typeof RestaurantDetailPage> = () => (
 <>
   <RestaurantDetailPage />
   <div id="modal" />
 </>
);
WithModalOpen.play = async ({ canvasElement }) => {
 const canvas = within(canvasElement);
 const item = await canvas.findByText(/Cheeseburger/i);
 await userEvent.click(item);
 await expect(canvas.getByTestId('modal')).toBeInTheDocument();
};
WithModalOpen.parameters = {
 msw: [rest.get(BASE_URL, (req, res, ctx) => res(ctx.json(restaurants[0])))],
};

Stories（故事）是测试的起点

编写 stories（故事）是你开发过程中的自然一部分。你可以轻松地将它们与其他工具结合使用，以验证 UI 的不同方面。

👀 可视化测试会捕获每个 story（故事）的屏幕截图，然后将其与基线进行比较，以检测外观和集成问题。

♿ 可访问性测试会捕获与视觉、听觉、行动能力、认知、言语或神经系统障碍相关的可用性问题。Storybook

🕹️ 交互测试通过触发事件并确保状态按预期更新来验证组件功能。

📥 将stories（故事）导入到 Playwright 或 Cypress 中测试用户流程。

通过自动生成文档避免重复

仅仅通过查看组件的代码，几乎不可能分辨出它的外观或功能。这通常会导致混淆，并且团队最终会重复开发组件。通过文档化你的组件可以避免这个问题。

但应用由数百个组件构建而成，维护文档具有挑战性。Storybook 的Docs 插件提供了一种更精简的替代方案。它使用 stories（故事）为你的组件自动生成文档。

文档是使用你的代码生成的，因此它始终保持最新。Stories（故事）变成了实时示例，并且该插件使用组件类型和 docgen 注释生成一个args table。

你可以使用 Storybook CLI 将其构建为静态站点并与你的团队共享。

UI 开发需要专门的工具

专门的工具帮助你隔离和开发技术栈的各个层。想想 Docker、MongoDB Compass、Postman 和 New Relic。同样，Storybook 使你能够隔离 UI 层。

Storybook 是构建、测试和文档化 UI 的工作坊。在开发过程中，你将编写 stories（故事）来捕获组件的所有状态和变体。然后将这些 stories（故事）与你喜欢的工具一起用作测试用例，或使用它们自动生成文档。

本文仅触及 Storybook 如何融入你的全栈开发工作流的皮毛。查看以下指南，深入了解使用 Storybook 的工作流

• UI 测试手册
• 使用 Storybook 构建页面
• 在测试中导入 stories（故事）