2022 年为什么选择 Storybook？

世界各地的团队使用 Storybook 来支持他们的前端工作流程。但其使用方式可能差异很大。微软使用它来记录他们的 Fluent 设计系统。Mozilla 在隔离环境中开发其 Web 应用页面。而 BBC 则自动化了针对所有区域读者的测试。

Storybook 广泛的应用场景使得新用户难以理解其核心价值。为什么开发者在 2022 年实际使用 Storybook？本文将分解 Storybook 的是什么、如何用以及为什么，以帮助你决定它是否适合你。

前端开发很简单……对吧？

在我们开始之前，让我们消除软件工程中最普遍的误解：“前端很简单”。

响应式网页设计将每个用户界面从一个变成了 10 个、100 个、1000 个不同的用户界面——每个都有独特的限制。随着时间的推移，设备、浏览器、可访问性、性能和异步状态等额外的 UI 要求堆积如山。这最终将更多复杂性推向了前端。

像 React、Vue 和 Angular 这样的组件驱动工具帮助将复杂的 UI 分解成简单的组件，但它们并非万能。随着前端的发展，组件数量会急剧增加。成熟的项目可能包含数百个组件，产生数千种不同的变体。

更复杂的是，这些 UI 调试起来很痛苦，因为它们纠缠在业务逻辑、交互状态和应用上下文中。

将 UI 复杂性的爆炸式增长想象成用户界面多重宇宙——一个由离散变体组成的庞大集合。在这个多重宇宙中进行开发就像在一个令人费解的迷宫中穿梭，充满了限制和陷阱。那么，你如何应对这一切呢？

如何在用户界面多重宇宙中进行开发

想象一下，有一张地图可以跟踪到每个组件的所有可能的 UI 变体：移动端的购物车、暗模式下的网络加载、高对比度主题的首页。

过去，你必须启动整个应用，导航到一个页面，然后扭曲 UI 使其进入正确的状态。这浪费了大量时间，并阻碍了前端开发。

如果你有一个应用支持的所有 UI 状态的地图，你就可以跳到 UI 中的任何一个位置，并像用户看到的那样查看它。然后你可以对这些状态运行自动化测试来捕获 bug，对其进行静态分析，甚至生成 UI 文档。这就是“Stories”被发明的原因。

Stories 在隔离环境中捕获 UI 状态

现在，每一个 UI 片段都是一个组件。组件的超能力在于，你无需启动整个应用就能看到它们如何渲染。你可以通过传入 props、模拟数据或伪造事件，在隔离环境中渲染特定的变体。

Stories 是一种声明性语法，用于提供 props 和模拟数据来模拟组件的变体。它们是 Storybook 背后的核心概念。每个组件可以有多个 stories。每个 story 允许你演示该组件的特定状态，以验证外观和行为。

你为细粒度的 UI 组件状态编写 stories，然后使用这些 stories 在开发、测试和文档编写过程中验证外观。

Storybook 跟踪 Stories

Storybook 被打包成一个小的、仅用于开发的工作坊，与你的应用并行存在。它提供了一个隔离的 iframe 来渲染组件，不受应用业务逻辑和上下文的干扰。这有助于你专注于组件的每个变体，即使是那些难以触及的边缘情况。

随着产品 UI 的扩展，Storybook 成为一个活生生的目录，组织着每个 UI 组件及其 stories。在开发过程中，将其在与应用分离的 Node 进程中运行。这样你就可以随时访问任何 story，而无需启动你的整个应用。

听起来像是额外的工作…

开发者通常在其应用的上下文中构建 UI 组件和状态。但在应用中，组件与杂乱的业务逻辑、应用上下文和全局状态绑定，使得调试变得棘手。通过在 Storybook 的隔离环境中进行开发，你可以避免这些浪费时间的复杂情况。

开发者为了更新一些 CSS 而启动整个技术栈的情况并不少见。这不仅麻烦，你还会浪费时间等待整个应用重新构建。Storybook 提供了一个更轻量级的替代方案，只构建 UI 层。这样你就可以专注于单个组件。

将应用 UI 置于正确的状态以开始工作是具有挑战性的。你需要放入临时数据来触发一个状态，注释掉代码来查看一个空状态，或者摆弄开发者工具来模拟一个加载状态。Stories 是可移植的夹具，允许你提供模拟数据、提供者甚至网络请求，以便按需生成特定的组件状态。

优势

当你编写 stories 时，你将免费获得一系列额外的好处。

📝 开发更可靠耐用的 UI
隔离组件和页面，然后将它们的用例作为stories进行跟踪。验证 UI 中难以触及的边缘情况。使用插件模拟组件所需的一切——上下文、API 请求、设备功能等。

✅ 更省力、更稳定地测试 UI
Stories 是一种实用且可重现的方式来跟踪 UI 状态。在开发过程中使用它们进行即时测试。Storybook 提供了用于自动化可访问性、交互和视觉测试的内置工作流程。或者将 stories 导入其他JavaScript 测试工具，将它们用作测试用例。

📚 记录 UI 以供团队复用
Storybook 是你 UI 的唯一事实来源。Stories 索引了所有组件及其各种状态，使你的团队易于查找和复用现有 UI 模式。Storybook 还能从这些 stories 自动生成文档。

📤 分享 UI 的实际工作方式
Stories 展示了 UI 的实际工作方式，而不仅仅是它应该如何工作的图片。这使得每个人都能了解当前生产环境中的情况。发布 Storybook 以获得团队成员的批准。或者将它们嵌入到 wiki、Markdown 和 Figma 中，以简化协作。

一次编写 stories，随处复用

Storybook 由组件 Story 格式 (CSF) 提供支持，这是一种基于 JavaScript ES6 模块的开放标准，用于表示组件变体。这使得开发、测试和设计工具之间可以相互操作。每个 story 都被导出为一个 JavaScript 函数，使你能够将其与其他工具一起复用。没有供应商锁定。

将 stories 与 Jest 和 Testing Library 一起复用，以验证交互。将其放入 Chromatic 进行视觉测试。使用 Axe 审计 story 的可访问性。或者使用 Playwright 和 Cypress 测试用户流程。复用可以在没有额外维护成本的情况下解锁更多工作流程。

无需繁重工作即可构建 UI

77% 的开发者认为，现在的开发比 10 年前更复杂。尽管 JavaScript 工具取得了进步，但开发者仍然面临越来越棘手的前端挑战。

Storybook 专门构建，旨在帮助你更快地开发复杂的 UI，同时提供更高的可靠性和更低的维护成本。Storybook 被数百家领先公司和数千名开发者使用也就不足为奇了。

随着 7.0 即将到来，Storybook 将持续改进。以下是对未来的展望

• ✅ 核心框架的“开箱即用”服务水平协议 (SLA)
• ⚡️ 性能全面改进，减少启动和构建时间
• 💅 设计和可用性焕然一新
• 🧩 集成流行的 JavaScript 工具
• 🔬 交互测试更新和新的测试运行器
• 📕 文档插件升级到 2.0