UI组件体系结构如何解决组织问题

最新推荐文章于 2022-06-24 15:52:02 发布

钱曙光

最新推荐文章于 2022-06-24 15:52:02 发布

阅读量358

点赞数

文章标签：库设计更新选择代码

本文链接：https://blog.csdn.net/qiansg123/article/details/80131805

版权

原文：How UI Component Architecture Can Solve Organizational Problems
作者： Steve Armstrong
翻译：lloog

译者注：在本文中，作者讨论了UI组件架构的概念，以及如何帮助你提高Web开发团队的速度和效率。

UI组件是一个非常困难的问题。只是选择一个UI框架或者在一些设计模拟上进行迭代，一切都会得到解决。对吗?

问题是，我们解决问题的大部分方法都来自于研究小项目。在小型项目中，我们可以使用一个样式表，或者在UI框架上迭代。

在一个使用大量的产品的大型组织中，这不会奏效。以下是可能出错的细节：

缺乏规划和架构

设计师为产品创建高保真的模型。
前端团队将设计实现到应用程序中。
应用程序大小的增长。
随着应用的发展，前端团队创建了一个库来“共享”代码。

浪费时间和停滞

产品需要对其中一个组件进行更改，但该组件现在在20-30页。
开发人员不愿做出改变，因为担心它会在其他地方“崩溃”。
由于团队拥有站点的不同部分，开发人员甚至不知道什么可能会中断。
瓶颈的产生是因为变化是高风险的。

不一致

现在产品负责人“A”她不喜欢一个选择框，所以她让设计师模拟出了一个她喜欢的新的选择框。
创建了一个新的一次性组件，它将被输入到代码库中，而不需要团队的其他成员对此进行了解。
现在有两个选择框。
选择框的更改不会在应用程序中传播。
现在，不仅存在瓶颈，还存在设计上的不一致。这一过程也缺乏团队的支持。

高风险/复杂性和条式代码

现在有人提交另一个设计请求。
全局样式表的尺寸越来越大，以至于掩盖任何其他样式。
该组件引用了一种基础样式，它将以一种不受欢迎的方式更新许多内容。
所以创建样式拼图，重要的是添加，现在…
认真的…开发人员已经开发结束了，设计师已经退出了，产品主人仍然在问为什么简单的改变是如此难以做到。
幸运的是，有非常聪明的人努力解决这些问题。那么我们如何解决呢？下面这是如何添加一些结构的清单：

步骤1：构建组件库

即使您的组件库引用了一组开源组件，也可以构建自己的库和版本。不仅如此，为库中的所有组件创建包装器。这样，如果您需要将某些东西交换出来，则不需要更改外部API。您只需要修改实现细节。

组件库应该是应用程序的核心。所有的应用程序都需要这个库。不要在您的应用程序中编写组件和“向后移植”，而是在前面的组件上工作。这将生成更好的代码和更有意义的应用程序。

组件库的另一个优点是所有开发人员可以隔离和观察更改。特别是如果您正在管理GitHub中的代码，并在在合并之前需要提取请求。

在一个单一的应用程序中，很容易将变更转移到一个导致不一致的功能分支上。有了一个组件库，人们就可以抵制牛仔编程。

步骤2：将您的整体前端拆分成较小的应用程序

如果您的应用程序有很多页面，那么您应该尝试将所有这些页面移动到它们自己的SPA(单个页面应用程序)中。这个系统的美妙之处就在于，当您对组件库进行更改时，您可以对所有应用程序进行渐进的更新。它使你不必去做“一个巨大的更新”。

这减少了开发人员对更改导致更多工作的担心。团队能够按照自己的进度管理更新。不需要有一个巨大的组织推动来更新一个按钮。

步骤3:使用CSS模块隔离组件设计

CSS模块允许有两种情况。第一，他们摆脱了全局类暴露的问题。这意味着当您为组件更新一个类时，您确切知道将会更新什么，因为样式的范围是相对于组件的。

第二个主要优势是，开发人员知道所有样式都在哪里。他们不必担心样式表会在一组普通的样式表上分散开来。

步骤4:使用交互样式指南作为用户体验、产品和工程之间的合同

任何组件库都应该能够发布交互式样式指南。对于开发人员、产品团队和设计人员来说，这是一个中间地带。它允许您隔离您的组件并独立地处理它们。你可以更快地工作，看到变化更快。最好的部分是，一旦您发布了更新，它将通过整个应用程序传播这些更改。

交互式样式指南就像是故事书。它不仅捕获了外观和感觉，还公开了响应组件的状态(在工作中对Vue支持)。

既然您已经知道了所有组件的位置，就不需要每次都交付高保真的模型了。设计师可以更多地关注行为、信息设计和用户体验。开发人员在开始新功能时不必担心设计问题。他们可以专注于业务逻辑和复杂的行为。

这种方法的潜在流程如下:

一个特性请求通过并被分解成一组组件。
前端开发人员决定该特性是否需要新的组件或更改。
如果没有，那么特性开发就可以开始了。
如果需要新的特性，开发人员将在组件库中创建一个特性分支。在产品、UX和其他开发人员的交互式风格指南中，这些更改将被评审。
一旦更改或新组件被批准，该分支就被移动到主文件中。
根据更改的不同，这个库的新版本是在semver之后创建的。
将应用程序的设计抽象为一组组件，并开发成组件库。该库应使用NPM进行版本控制。打破API或可能的主要设计变更将保证主要版本的更改。
应用程序的部分被分解为具有自己的package.json的SPA（单页面应用程序）。这允许他们以可控的方式对组件进行升级。
新组件或更改在开始特性开发之前就已经确定了。产品、UX和工程可以使用交互式样式指南在组件设计上进行协作，并在站点上看到一个“真实”的副本。更改并不可怕，因为如果存在与更改相关的风险，开发人员可以使用版本控制来减轻影响。另外，现在使用CSS模块对组件样式进行隔离，因此对组件“a”的更改不会影响组件“b”。
用户体验现在可以交付低精度的模拟组件，根据名称来引用组件。开发人员知道要使用哪些组件，不需要在“共享”代码的某个地方“钓鱼”。
另一个设计?没有问题。我们将在组件库中创建一个分支，并更新所有样式。当我们准备发布时，我们将创建一个主要的版本更新。问题就解决了。