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

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

作者:互联网

为什么选择 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 继续变得更好。以下是对未来的展望:

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

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

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