🕴🏽 👨🏾‍⚖️ 🦋 测试如何帮助您创建自己的UI-kit 👨‍👨‍👦‍👦 👃 👨🏾‍🔧

对于那些不喜欢冗长介绍的人，让我们直接得出结论-为您的组件编写测试。说真的，这就是我要说的。但是，我们不要太在意这个，想象一下这些是定理（一个前端定理）的结论。而现在，我们将需要拿出证据。

所以，让我们想象。在IT开发中，不仅在前端，后端或设计，编程语言，管理，方法论等方面有什么共同点？我猜有一个主要原理-分解和成分。

无论我们是否想要，无论我们是否了解自己编写的内容，我们都使用组件，我们总是将任务分解成较小的任务。

我想到了百万分之一的时间，为我们内在的漂亮UI包编写表的下一个实现，我想-我需要做哪些初步工作？到底应该写什么？从哪里开始？

与队友交谈后，我听到了一些提示。我只是真的很喜欢一个。由于我是奇异性的爱好者，并且喜欢使用graphql，所以有人要求我不要写任何东西。使用{table}标签，一些神经网络将处理该表，创建graphql查询，并使用数据填充该表。简单的一个:)。
但是正如他们所说-“任何系统中都存在致命缺陷”，我开始考虑“如何发明自己的车轮”。聪明的人已经想出了摆在我们面前的一切。千禧世代，我们只能重新排列盘子并以不同的方式命名。

我准备介绍自己的一套原型UI套件原理-IDOLS！让我们来看看！

我代表接口隔离，D代表依赖倒置，O代表……只是在开玩笑，当然，它是SOLID

将组件工作正式化的所有尝试都减少了。这些原则可以无限期扩展，但最终的结果总是减少到这五个。当然，如果我们谈论的是OOP或CBP（基于组件的编程）。

让我们将这些原理加载到我们的“ RAM”中，并仔细研究这些要点。

S-单一责任

嗯，请不要...

针对不同情况使用特殊的组件。您不应该制造一个可以同时切掉某些东西和拧下东西的组件。做两个不同的部分。

O-打开/关闭

该原则说，您的组件应该开放以便改进，而封闭则可以进行修改，换句话说，您可以在另一个组件中重用您的组件，但是如果组件已经遵循单一职责原则，则不应更改它。

L-里斯科夫替代

作为先前原理的一个小扩展，可以使用子类的任何实例来代替基类的实例。我不确定该原则如何适合组件的上下文，很可能只是先前原则的重复。

I-接口隔离

我们将进一步讨论这一点，现在我们可以说，给其他开发人员很多小接口比提供一个大接口更好，但是可以解决所有问题。让我们比较下面的示例。

一切都在一个地方配置，无法维护，不可重用...

一切都作为构造函数，可以随意组装

D-依赖倒置

应用程序的各个部分不应该相互了解的原理，应该仅通过公共接口继承。在这里，我们更多地讨论重用和减少组件的连接性。 Table的组件不需要知道数据的来源和来源，只需要知道条件数据加载器即可。

但是，一种观点对我们来说还不够。由于在这种情况下，很容易成为该想法的人质。因此，另一方面，我们从设计方面来看组件的开发。

在这种情况下，我们将考虑一种越来越流行的设计方法，即原子设计。相对而言，原子设计是将UI元素与来自物理和生物学的层次结构进行比较的另一种分解UI元素的方法。

因此，让我们看看什么是原子设计。

代币

第一级是令牌，有人在模型中包含了令牌，有人没有，但是值得一提。令牌（颜色，字体大小，间距，动画）是我们可以在任何平台上重用的所有原语。

值得注意的是，原子设计的层次结构越高，可重用性的降低就越大。但是稍后会更多。

原子

接下来是原子（没有逻辑，输入，按钮的简单组件）。第一层是组件的显示位置及其输出。原子没有任何状态，仅显示静态样式的标记。

分子

原子然后组装成分子（更复杂的组分键）。分子可以具有自己的状态，但这不是业务状态，可以是配置状态（例如isOpen）。我们可以猜测，分子更像是顶级业务状态与我们如何根据此状态排列原子或子级内容之间的代理。

分子是我们可以满足样式要求的最后一个层次。

生物体

分子组成生物（组成部分的整体工作组），例如，页眉，页脚等。有机体对其他生物和样式一无所知，这就是我们的“ DNA容器”，也是我们的业务逻辑，它们知道如何显示这一点以及何时应该对其进行更改。

模板/页面

原子设计的最后一个层次。此级别代表生物体组，当前页面包括在内。

我们可以通过分子在页面上构成生物体，然后将该页面称为“布局”，并重复使用它来改变其中的生物体。

使用这两种方法（SOLID和Atomic），我们将在开发组件时尝试提出一些建议。因此，我们需要这些建议才能理解，当我们说“创建另一个组件”时，我们到底在做什么。

考虑到这些组件将可以与其他开发人员一起使用，因此在放置接口和API时，请牢记这一点。

我们可以开始开发理想的界面。

首先要做的不是开始开发理想的界面。理想的界面是它的不足。接口是您所做的事情与开始工作之间的障碍。这是一种痛苦，必须避免。

因此，最好的解决方案是：

这顺利地带给我们以下内容：

1.确定组件的状态

如果使用此组件的开发人员第一次看到它，请对其进行一些入门，随着设置复杂性的增加，将该组件转换为新状态，并告知开发人员。

状态在不同时间可以完全不同。
空→下载→正在加载→正在加载另一部分→已完全加载→错误等。
指导开发人员完成所有可能的状态组合，并在工作时教他们。

在处理状态问题时，人们不由自主地发现了默认状态问题。因此，第二个建议。

2.定义默认值

使用此项目，您可以用一块石头杀死两只鸟，您不仅可以向开发人员提供应用程序正在发生的基本信息，而且对您来说，缺少一个或另一个变量也不会破坏所有功能。另外，原则上也不需要进行难看的检查。

此外，如果开发人员仍想添加设置，则有必要对此提供帮助，并且不要干预。

根据理查德·格雷戈里（Richard Gregory）的理论，人们根据以前的视觉体验来探索周围的世界。而且，如果您的组件在后台进行了某些更改，并且您想让开发人员知道它，那么可以预测地调用钩子和回调。

3.无需重新发明轮子

不是changePasswordInputValue，而是onChange，因为如果它是您的“分子”，则将始终清楚该值将发生什么变化。

好吧，尝试遵循一般的命名规则，事件的on前缀，动作的动词，并且如果在一个地方使用布尔标志isDisabled，然后在各处使用它，则不再需要isEnabled，保持一致。

接下来要注意的是，当您完成对组件的操作后，将其传递给其他开发人员，将进一步处理它。如果您的组件出了问题，您将不得不开始一个新的开发周期：开发人员发现错误或无法做他们想要的事情→打开问题→您正在寻找时间来修复它→考虑一致性→修复→更新软件包→向开发人员宣布→更新软件包→尝试一周前要做的事情。

4.尝试给予开发人员尽可能多的控制权

就像他们现在正在编写此组件一样-SOLID原理之一的直接结论
假设您允许将一段文本传递到您的组件。如果存在此文本，则将显示该文本，但您也要记住有关默认状态的规则，并写出以下条件：如果不传输文本，则显示默认文本。因此，以一种良好的语气，它将使开发人员明确指出此处不需要该文本。

好吧，如果您认为我们首先开始使用原子组件，那么下面的建议来自于此。

5.保持组件清洁干燥，以免抽象泄漏（KISS）。

如何遵循呢？ -很简单，不要在组件中编写代码。仅模板及其如何绘制输入数据。如果您需要制作地图，进行过滤，对数据进行缩减，那么您将无法在外部重新定义常量，您的模板将使用文字，这是错误的-它不再是原子，而在其他方面则更难以维护。必须避免这种情况。

因此，我们获得了一些建议的简短清单，可以遵循这些建议。

定义状态
定义默认值
不要重新发明轮子
让他们（开发者）统治
保持简单，愚蠢（KISS）

但是我们的大脑如此安排，以至于在写完三个部分之后，我们开始认为我们不需要查看此列表即可检查所有要点。而且我们知道，在较复杂和较容易的任务中，我们总是选择较容易的一项，因为它可以那样工作。我们热爱节约能源，我们需要储备能源。因此，此类列表始终会在融合之前丢失，直到出现更好的情况为止，而我们会继续将错误列表修正到主列表中。

只有了解到，对我们来说明智的选择通常要比连续两周不睡觉，修复生产中的错误要容易得多，我们才会使任务更加困难（出于客观原因）并且更加容易（对于我们而言）原因）。

那么如何欺骗我们的大脑并提出建议呢？

好吧，让我们尝试使其自动化。