首页 > 其他分享> > 为什么选择 2022 年的故事书？

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

2022-09-02 01:01:36 作者：互联网

故事书有什么大惊小怪的

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

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

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

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

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

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

将 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 函数，使您可以在其他工具中重复使用它们。没有供应商锁定。

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

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

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

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

标签：为什么,故事,状态,故事书,应用程序,Storybook,UI,2022,组件
来源： https://www.cnblogs.com/amboke/p/16648352.html