为什么选择 2022 年的故事书？

故事书有什么大惊小怪的

世界各地的团队都使用 Storybook 来支持他们的前端工作流程。但是它的使用方式可能会有很大的不同。 Microsoft 记录了他们的 Fluent 设计系统。 Mozilla 为他们的 Web 应用程序单独开发页面。而 BBC 会自动为每个地区的读者进行测试。

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

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

在开始之前，让我们先澄清一下软件工程的最大误解：“前端很简单”。

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

React、Vue 和 Angular 等组件驱动工具有助于将复杂的 UI 分解为简单的组件，但它们并不是灵丹妙药。随着前端的增长，组件的数量也在增加。成熟的项目可以包含数百个组件，这些组件会产生数千个离散的变化。

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

将 UI 复杂性的爆炸视为 用户界面多元宇宙 ——一大堆离散的变化。这个多元宇宙的发展是一个令人费解的限制和陷阱的迷宫。那么你如何浏

如何在用户界面multiverse中开发

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

过去，您必须启动应用程序、导航到页面并将 UI 扭曲到正确的状态。这是对时间的巨大浪费，并且会阻碍前端开发。

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

故事单独捕获 UI 状态

现在的每一块 UI 都是一个 零件 .组件的超能力在于，您无需启动整个应用程序即可查看它们的呈现方式。您可以通过传入道具、模拟数据或伪造事件来单独呈现特定的变体。

故事 是一种声明性语法，用于提供道具和模拟数据以模拟组件变化。它们是 Storybook 背后的核心结构。每个组件可以有多个故事。每个故事都允许您展示该组件的特定状态以验证外观和行为。

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

故事书记录故事

Storybook 被打包成一个小型的、仅用于开发的、 作坊 与您的应用程序一起存在。它提供了一个隔离的 iframe 来呈现组件，而不受应用程序业务逻辑和上下文的干扰。这有助于您将开发重点放在组件的每个变体上，甚至是难以触及的边缘案例。

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

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

开发人员经常在其应用程序的上下文中构建 UI 组件和状态。但在应用程序中，组件与杂乱的业务逻辑、应用程序上下文和全局状态相关联，使得调试变得棘手。您可以通过在 Storybook 的孤立环境中进行开发来回避这些浪费时间的复杂情况。

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

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

Storybooks for Microsoft, Shopify, and Hewlett Packard Enterprise

好处

当你写故事时，你会免费获得一堆额外的好处。

**开发更耐用的 UI
** 隔离组件和页面，然后跟踪它们的用例 故事 .验证难以触及的 UI 边缘案例。使用插件来模拟组件所需的一切——上下文、API 请求、设备功能等。

✅ **轻松测试 UI
** 故事是跟踪 UI 状态的一种实用的、可重复的方式。在开发过程中使用它们对 UI 进行现场测试。 Storybook 提供了用于自动化的内置工作流程 可访问性 , 相互作用 ， 和 视觉的 测试。或者将故事作为测试用例，将它们导入其他 JavaScript 测试工具 .

**文档 UI 供您的团队重复使用
** Storybook 是 UI 的唯一真实来源。 Stories 索引您的所有组件及其各种状态，使您的团队可以轻松找到和重用现有的 UI 模式。故事书也会自动生成 文件 从那些故事中。

**分享 UI 的实际工作原理
** 故事展示了 UI 的实际工作方式，而不仅仅是它们应该如何工作的图片。这使每个人都对当前生产的内容保持一致。 出版故事书 得到队友的认可。或者 嵌入 它们在 wiki、Markdown 和 Figma 中以简化协作。

一次写故事，到处重复使用

故事书由 组件故事格式 ，一个基于 JavaScript ES6 模块的开放标准，用于组件变体。这实现了开发、测试和设计工具之间的互操作。每个故事都导出为 JavaScript 函数，使您可以在其他工具中重复使用它们。没有供应商锁定。

重用故事 是 和 测试库 来验证交互。把它们放进去 彩色 用于视觉测试。审计故事可访问性 斧头 .或测试用户流程 剧作家 和 柏 .重用可解锁更多工作流程，无需额外维护成本。

无需繁重的工作即可构建 UI

77% 的开发者 同意发展比 10 年前更复杂。尽管 JavaScript 工具取得了进步，但开发人员仍然面临着越来越棘手的前端挑战。

Storybook 旨在帮助您更快地开发复杂的 UI，同时具有更高的耐用性和更低的维护成本。 Storybook 被 100 多个人使用也就不足为奇了。 龙头企业 和成千上万的 开发商 .

随着 7.0 即将到来，Storybook 继续变得更好。以下是对未来的展望：

• ✅ 为我们的核心框架提供“它只是工作”的 SLA
• ⚡️ 性能大修以减少启动和构建时间
• 设计和可用性更新
• 流行 JavaScript 工具的集成
• 交互测试更新和新的测试运行器
• 文档插件改版为 2.0

版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明

本文链接：https://www.qanswer.top/9626/50130200