为什么在 2022 年选择 Storybook？

世界各地的团队都在使用 Storybook 来驱动他们的前端工作流程。但它的使用方式可能千差万别。微软记录了他们的 Fluent 设计系统。Mozilla 隔离地开发他们的 Web 应用程序页面。而 BBC 则为每个地区的读者自动化测试。

Storybook 用例的广泛性使得新手很难理解其核心价值。开发者在 2022 年实际使用 Storybook 的原因是什么？本文分解了 Storybook 背后的内容、方式和原因，以帮助您决定它是否适合您。

前端开发很容易……对吧？

在我们开始之前，让我们消除软件工程中最常见的误解：“前端很容易”。

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

组件驱动的工具（如 React、Vue 和 Angular）有助于将复杂的 UI 分解为简单的组件，但它们并非万能药。随着前端的增长，组件的数量激增。成熟的项目可能包含数百个组件，这些组件产生数千个离散的变化。

更复杂的是，这些 UI 难以调试，因为它们与业务逻辑、交互状态和应用程序上下文纠缠在一起。

将 UI 复杂性的爆炸式增长视为用户界面多元宇宙——一个庞大的离散变化集合。在这个多元宇宙中开发是一个令人费解的约束和陷阱迷宫。那么，您如何驾驭这一切呢？

如何在用户界面多元宇宙中开发

想象一下一张地图，它可以跟踪每个可能的 UI 变化，直至组件级别：移动设备上的购物车、暗模式下的网络加载、高对比度主题的主页。

过去，您必须启动应用程序，导航到页面，并将 UI 扭曲到正确的状态。这非常浪费时间，并拖累了前端开发。

如果您有一张地图，显示您的应用程序支持的每个 UI 状态，您可以跳转到 UI 中的任何位置，并像您的用户一样看到它。然后，您可以针对这些状态运行自动化测试，以捕获错误、静态分析它们，甚至生成 UI 文档。这就是“Stories”（故事）被发明的原因。

Stories 隔离地捕获 UI 状态

现在，每个 UI 组件都是一个组件。组件的超能力在于您无需启动整个应用程序即可查看它们的渲染方式。您可以通过传入 props、模拟数据或伪造事件来隔离地渲染特定的变体。

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

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

Storybook 跟踪 stories

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

随着产品 UI 的扩展，Storybook 成为一个活生生的目录，组织每个 UI 组件及其 stories。在开发期间，在与应用程序分离的节点进程中运行它。这样，您可以随时转到任何 story，而无需启动整个应用程序。

这听起来像是额外的工作…

开发人员通常在其应用程序的上下文中构建 UI 组件和状态。但是在应用程序中，组件与混乱的业务逻辑、应用程序上下文和全局状态连接在一起，这使得调试变得棘手。您可以通过在 Storybook 的隔离环境中开发来避免这些浪费时间的复杂情况。

开发人员为了更新一些 CSS 而启动整个堆栈的情况并不少见。这不仅麻烦，而且您还会浪费时间等待整个应用程序重建。Storybook 通过仅构建 UI 层来提供更轻便的替代方案。这样，您可以将精力集中在单个组件上。

使应用程序 UI 处于正确状态以开始工作具有挑战性。您放入临时数据以触发状态，注释掉代码以查看空状态，或摆弄 devtools 以模拟加载状态。Stories 是可移植的 fixtures，可让您提供模拟数据、providers 甚至网络请求，以按需生成特定的组件状态。

优势

当您编写 stories 时，您将免费获得许多额外的好处。

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

✅ 以更少的精力和无故障地测试 UI
Stories 是一种实用、可重复的方式来跟踪 UI 状态。在开发期间使用它们来抽查 UI。Storybook 为自动化可访问性、交互和视觉测试提供内置的工作流程。或者通过将 stories 导入其他 JavaScript 测试工具，将 stories 用作测试用例。

📚 为您的团队记录 UI 以便重用
Storybook 是您 UI 的单一事实来源。Stories 索引您的所有组件及其各种状态，使您的团队可以轻松找到和重用现有的 UI 模式。Storybook 还从这些 stories 自动生成文档。

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

编写一次 stories，随处重用

Storybook 由组件故事格式提供支持，这是一种基于 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