ipad ui kit
So, let’s imagine. What is common in IT-development, not only in the frontend, backend or design, programming languages, management, methodologies and go on? I guess there is the one main principle — decomposition and components.
所以，让我们想象。 在IT开发中，不仅在前端，后端或设计，编程语言，管理，方法论等方面有什么共同点？ 我猜有一个主要原理-分解和成分。
Whether we want it or not, whether we understand what we write or not, we work with components, we always decompose tasks into smaller ones.
无论我们是否想要，无论我们是否了解自己编写的内容，我们都使用组件，我们总是将任务分解成较小的任务。
And getting together for the millionth time to write the next implementation of the table for our inner beautiful UI-kit, I thought — what preliminary work do I need to do? What exactly should be written? And where to start?
我想百万分之一的时间为我们内在的漂亮UI包编写表的下一个实现，我想-我需要做哪些初步工作？ 到底应该写什么？ 从哪里开始？
After talking with teammates, I heard a few tips. I just really liked one. Since I am a fan of singularity and a bit of graphql, I was asked not to write anything at all. Use the {table} tag and some neural network will process this table, create a graphql query, and populate the table with data. Easy one :).
与队友交谈后，我听到了一些提示。 我真的很喜欢。 由于我是奇异性的爱好者，并且喜欢使用graphql，所以有人要求我不要写任何东西。 使用{table}标签，一些神经网络将处理该表，创建graphql查询，并使用数据填充该表。 简单的一个:)。
But as they say — “there is a fatal flaw in any system”, I began to think about “how to invent my own wheel”. And smart people have already come up with everything before us. We, the millennials, can only rearrange the plates and name things differently.
但是正如他们所说的那样-“任何系统都存在致命的缺陷”，我开始思考“如何发明自己的轮子”。 聪明的人已经想出了摆在我们面前的一切。 千禧世代，我们只能重新排列盘子并以不同的方式命名。
I am ready to introduce my own set of principles of prototyping UI-kits — I.D.O.L.S.! Let’s take a look!
我准备介绍自己的一套原型UI套件的原理— IDOLS！ 让我们来看看！
I stands for Interface segregation, D stands for Dependency inversion, O stands… just kidding, of course, it is S.O.L.I.D.
我代表接口隔离，D代表依赖倒置，O代表……只是在开玩笑，当然，它是SOLID
All attempts to formalize work with components are reduced to this. These principles can be expanded indefinitely, but everything is always the final result is reduced to this five. If we are, of course, talking about OOP or CBP (component-based programming).
将组件工作正式化的所有尝试都减少了。 这些原则可以无限期扩展，但最终的结果总是减少到这五个。 当然，如果我们谈论的是OOP或CBP(基于组件的编程)。
Let’s load these principles into our “RAM” and go through the points.
让我们将这些原理加载到我们的“ RAM”中，并仔细研究这些要点。
S —单一责任 (S — Single Responsibility)
Hmm, please don’t …
嗯，请不要…
Use a special component for different cases. You should NOT make a component, which will able to cut something off and wrench something down at the same time. Make two different pieces.
针对不同情况使用特殊的组件。 您不应该制造一个可以同时切掉某些东西并拧紧东西的组件。 做两个不同的部分。
O —打开/关闭 (O — Open/Closed)
The principle says that your components should be open for improvements and closed for modifications, in other words, you can reuse your component within another component, but you should not change your component if it already obeys the principle of single responsibility.
该原则表示，您的组件应该开放以便改进，而封闭则可以进行修改，换句话说，您可以在另一个组件中重用您的组件，但是如果组件已经遵循单一职责原则，则不应更改它。
L — Liskov替代 (L — Liskov substitution)
A small extension of the previous principle, any instance of a subclass can be used instead of an instance of the base class. I’m not sure how this principle fit the components’ context, most likely it will be just a duplication of the previous principle.
作为先前原理的一个小扩展，可以使用子类的任何实例来代替基类的实例。 我不确定此原理如何适合组件的上下文，很可能只是先前原理的重复。
I —接口隔离 (I — Interface segregation)
We’ll talk about this even further, now we can say that it’s better to give the other developer a lot of small interfaces than one big one but for everything. Let’s compare the examples below.
我们将进一步讨论这一点，现在我们可以说，给其他开发人员很多小接口比提供一个大接口更好，但是却要满足所有要求。 让我们比较下面的示例。
Everything is configuring in one place, unmaintainable, non-reusable…
一切都在一个地方配置，无法维护，不可重用...
Everything as a constructor, assemble as you like and conveniently
一切都作为构造函数，可随意组装
D —依赖倒置 (D — Dependency inversion)
The principle that the various parts of the application should not know anything about each other, and should be inherited only through common interfaces. Here we are talking more about reuse and reducing the connectedness of components. The component of the Table does not need to know where and how the data comes from, it only needs to know the conditional DataLoader, which can be anything.
应用程序的各个部分不应该相互了解的原理，应该仅通过公共接口继承。 在这里，我们更多地讨论重用和减少组件的连接性。 表的组件不需要知道数据的来源和来源，只需要知道条件数据加载器即可。
But one point of view is not enough for us. Since in this situation, it is very easy to become a hostage to this idea. Therefore, we look at the development of components on the other hand, from the design side.
但是，一种观点对我们来说还不够。 由于在这种情况下，很容易成为这个想法的人质。 因此，另一方面，我们从设计方面来看组件的开发。
In this case, we will consider one of the increasingly popular design approaches, namely atomic design. Relatively speaking, the atomic design is another way to decompose UI elements by comparing them with a hierarchy from physics and biology.
在这种情况下，我们将考虑一种越来越流行的设计方法，即原子设计。 相对而言，原子设计是将UI元素与物理和生物学层次结构进行比较的另一种分解UI元素的方法。
So let’s take a look, what is atomic design.
因此，让我们看一下什么是原子设计。
代币 (Tokens)
The first level is tokens, someone includes this in the model, someone does not, but it’s worth mentioning. Tokens (colours, font sizes, spacings, animations) are all the primitives that we can reuse on any platform.
第一层是令牌，有人在模型中包含了令牌，有人没有，但是值得一提。 令牌(颜色，字体大小，间距，动画)是我们可以在任何平台上重用的所有原语。
It is worth noting that the higher we are in the hierarchy in atomic design, the more re-usability decreases. But more on that later.
值得注意的是，原子设计的层次结构越高，可重用性的降低就越大。 但是稍后会更多。
原子 (Atoms)
Next are the atoms (simple components without logic, inputs, buttons). The first level is where the components appear and what they output. Atoms have not any state, only show static styled markup.
接下来是原子(没有逻辑，输入，按钮的简单组件)。 第一层是组件的显示位置及其输出。 原子没有任何状态，仅显示静态样式的标记。
分子 (Molecules)
The atoms then assemble into molecules (more complex component bonds). Molecules can have own state, but this is not a business state, it can be a configurational state (like isOpen). We can guess that molecules are more like a proxy between top business state and how we align our atoms or children content depending on this state.
原子然后组装成分子(更复杂的组分键)。 分子可以具有自己的状态，但这不是业务状态，可以是配置状态(例如isOpen)。 我们可以猜测，分子更像是顶级业务状态与我们如何根据此状态排列原子或子级内容之间的代理。
Molecules are the last level where we can meet styling.
分子是我们可以满足样式要求的最后一个层次。
生物体 (Organisms)
Molecules make up organisms (integral working groups of components), for example, a header, footer and so on. Organisms do not know anything about other organisms and styles, this is our “containers of DNA” our business logic, which know how to show this and when it should be changed.
分子组成生物(组成部分的整体工作组)，例如页眉，页脚等。 有机体对其他生物和样式一无所知，这就是我们的“ DNA容器”，也是我们的业务逻辑，它们知道如何显示这一点以及何时应该对其进行更改。
模板/页面 (Templates/Pages)
The last one level of atomic design. This level represents the groups of organisms, which current page included.
原子设计的最后一个层次。 此级别代表生物体组，当前页面包括在内。
We can make the composition of organisms on the page via molecules and then call that page as “layout” and reuse it changing our organisms inside it.
我们可以通过分子在页面上构成生物体，然后将该页面称为“布局”，并重复使用它来改变其中的生物体。
Using these two approaches (S.O.L.I.D. and Atomic), we will try to formulate some recommendations when developing components. So, those recommendations will be needed for us to understand, what exactly we are doing when we say “create another one component”.
使用这两种方法(SOLID和Atomic)，我们将在开发组件时尝试提出一些建议。 因此，我们需要这些建议才能理解，当我们说“创建另一个组件”时，我们到底在做什么。
Considering that, these components will get to work with other developers, we will keep this in mind when we will lay the interface and API.
考虑到这些组件将可以与其他开发人员一起使用，因此在放置接口和API时，请牢记这一点。
We can start developing our ideal interface.
我们可以开始开发理想的界面。
The first thing to start with is not to start developing an ideal interface. The ideal interface is its lack. An interface is an obstacle between what you did and when it starts to work. This is a pain, which has to be avoided.
首先要做的不是开始开发理想的界面。 理想的界面是它的不足。 接口是您所做的事情与开始工作之间的障碍。 这是一种痛苦，必须避免。
Thus, the best solution would be the following:
因此，最好的解决方案是：
This smoothly brings us to the following:
这顺利地带给我们以下内容：
1.确定组件的状态 (1. Determine the state of the component)
If a developer who uses this component sees it for the first time, do a little onboarding for it, translate the component into new states as the complexity of the settings increases and tell the developer about it.
如果使用此组件的开发人员第一次看到它，请对其进行一些入门，随着设置复杂性的增加，将该组件转换为新状态，并告知开发人员。
The states can be completely different at different times.
状态在不同时间可以完全不同。
Empty → Downloading → Loading → Loading another part → Fully loaded → Error, etc.
空→下载→正在加载→正在加载另一部分→已完全加载→错误等。
Guide the developers through all possible combinations of states, teach them while they work.
指导开发人员完成所有可能的状态组合，并在工作时教他们。
When dealing with state issues, one involuntarily stumbles upon the problem of default states. Because of it, the second recommendation.
在处理状态问题时，人们会不由自主地发现默认状态问题。 因此，第二个建议。
2.定义默认值 (2. Define default values)
With this item, you can kill two birds with one stone, you not only provide basic information to the developer what is happening with the application but for you, the absence of one or another variable will not be a surprise that breaks everything. Also, ugly checks for their presence in principle are not needed.
使用此项目，您可以用一块石头杀死两只鸟，您不仅可以向开发人员提供应用程序正在发生的基本信息，而且对您来说，缺少一个或另一个变量也不会破坏一切。 另外，原则上也不需要进行难看的检查。
Further, if the developer still wants to add settings, it is necessary to help him in this, and not to interfere.
此外，如果开发人员仍想添加设置，则有必要对此提供帮助，并且不要干预。
Given Richard Gregory’s theory, people explore the world around them based on previous visual experiences. And if your component changes something under its hood and you want to let the developer know about it, then call your hooks and callback predictably.
根据理查德·格雷戈里(Richard Gregory)的理论，人们根据以前的视觉体验来探索周围的世界。 而且，如果您的组件在其内部进行了某些更改，并且您想让开发人员知道它，则可以预测地调用钩子和回调。
3.无需重新发明轮子 (3. No need to reinvent the wheel)
Not changePasswordInputValue, but onChange, because if it is your “molecule”, it will always be clear what the value will change.
不是changePasswordInputValue，而是onChange，因为如果它是您的“分子”，则将始终清楚该值将发生什么变化。
Well, try to follow the general naming rules, the on prefix for events, verbs for actions, and if you use the boolean flag isDisabled in one place, then use it everywhere, you no longer need isEnabled, be consistent.
好吧，尝试遵循一般的命名规则，事件的on前缀，动作的动词，如果在一个地方使用布尔标志isDisabled，然后在各处使用它，则不再需要isEnabled，保持一致。
The next thing you should pay attention to is that when you finish working on the component, you pass it on, other developers will work with it further. And if something goes wrong with your component, you will have to start a new development circle: the developer finds a bug or cannot do something that they wants → opens issue → you are looking for a time to fix it → consider the consistency → fix → update packages → announce to developers → update packages → try to do what they wanted a week ago.
接下来要注意的是，当您完成对组件的操作后，将其继续传递，其他开发人员将进一步使用它。 如果您的组件出了问题，您将不得不开始一个新的开发周期：开发人员发现错误或无法做他们想要的事情→打开问题→您正在寻找时间来修复它→考虑一致性→修复→更新软件包→向开发人员宣布→更新软件包→尝试一周前要做的事情。
4.尝试给予开发人员尽可能多的控制权 (4. Try to give developers as much control as possible)
As if they wrote this component right now — a direct conclusion of one of the principles of S.O.L.I.D.
就像他们现在正在编写此组件一样-SOLID原理之一的直接结论
Suppose you allow a piece of text to be passed to your component. If this text is present, then it will be displayed, but you also remember the rule about default states and write the condition that if the text is not transmitted, then show the default text. So, in a good tone, it will give the developer explicitly indicate that the text is not needed here.
假设您允许将一段文本传递到您的组件。 如果存在此文本，则将显示该文本，但您也要记住有关默认状态的规则，并写下以下条件：如果不传输该文本，则显示默认文本。 因此，以一种良好的语气，它将使开发人员明确指出此处不需要该文本。
Well, if you consider that in the first place we start working with atomic components, then the following recommendation comes from here.
好吧，如果您认为我们首先开始使用原子组件，那么下面的建议来自于此。
5.保持组件清洁干燥，以免抽象泄漏(KISS)。 (5. Keep your components clean and dry so that abstractions do not leak (KISS).)
How to follow this? — quite simply, do not write code in your component. Only the template and how it draws the input data. If you need to make map, filter, reduce on the data, you have constants that cannot be redefined outside, your template uses literals, which is wrong — it’s not an atom anymore, but something else, it’s more difficult to maintain. This must be avoided.
如何遵循呢？ —很简单，不要在组件中编写代码。 只有模板及其如何绘制输入数据。 如果您需要制作地图，进行过滤，对数据进行缩减，您拥有无法在外部重新定义的常量，您的模板使用了文字，这是错误的-它不再是原子，而在其他方面则更难以维护。 必须避免这种情况。
So, we got a shortlist of recommendations that it would be nice to follow.
因此，我们获得了一些建议的简短清单，可以遵循这些建议。
- Define state 定义状态
- Define default value 定义默认值
- Don’t reinvent the wheel 不要重新发明轮子
- Let them ( devs ) rule 让他们(开发人员)统治
- Keep It Simple, Stupid ( KISS ) 保持简单，愚蠢(KISS)
But our brain is so arranged that after writing a couple of three components — we begin to think that we do not need to look into this list to check all the points. And we know that among the more complex task and the easier one, we always choose the easier one because it works like that. We love saving our energy, we need it, in reserve. Therefore, such lists are always lost in the confluence until better times, and we continue to bugfix to the master.
但是我们的大脑如此安排，以至于在写了三个部分之后，我们开始认为我们不需要查看此列表即可检查所有要点。 而且我们知道，在较复杂和较容易的任务中，我们总是选择较容易的一项，因为它的工作原理是这样的。 我们热爱节约能源，我们需要储备能源。 因此，此类列表始终会在融合之前丢失，直到出现更好的情况为止，并且我们会继续将错误列表修正到主列表中。
Only if we understand that making it wise for us, in general, will be easier than not to sleep for two weeks in a row, fixing bugs in production, we will make the task more difficult (for objective reasons) and easier (for our reasons).
只有了解到，对我们来说，明智的选择通常比连续两个星期不睡觉，修复生产中的错误要容易得多，我们才会使任务更加困难(出于客观原因)并且更加容易(对于我们而言)原因)。
How then to deceive our brain and make recommendations work?
那么如何欺骗我们的大脑并提出建议呢？
Well, let’s try to automate this.
好吧，让我们尝试使其自动化。
自动化 (Automatization)
We can use the eslint + lefthook bundle or any other git-hooks tool.
我们可以使用eslint + lefthook捆绑包或任何其他git-hooks工具。
We describe the rules of how we want to see our variables and how our code should be styled. We forbid magic numbers and literals in templates, we expect from us that we will write docks for our code immediately. We hang up these checks for a git hook and get automatic notifications that our code is bad and should be updated.
我们描述了如何查看变量以及如何设置代码样式的规则。 我们禁止模板中使用幻数和文字，我们期望我们将立即为代码编写停靠栏。 我们将这些检查挂起以获取git钩子，并自动收到有关我们的代码不正确的通知，应该对其进行更新。
But this is not a silver bullet and we cannot fulfil all the recommendations. Only a part.
但这不是灵丹妙药，我们无法实现所有建议。 只有一部分。
In this way, we cannot handle our possible states and can’t guarantee that other devs will get what they want. We can just assume, for example, that something will return anyway (aka default value) but no more.
这样，我们无法处理可能的状态，也无法保证其他开发人员会得到他们想要的东西。 例如，我们可以假设某个东西仍然会返回(也就是默认值)，但不会再返回。
Then you can try another way. Develop our components through SDD. Storybook Driven Development.
然后，您可以尝试其他方式。 通过SDD开发我们的组件。 故事书驱动的开发。
故事书驱动的开发 (Storybook Driven Development)
We have a story file in the form where we describe all the possible states of the component. And a storybook collecting these stories.
我们有一个故事文件，该文件的形式描述了组件的所有可能状态。 还有一本收集这些故事的故事书。
Our stories about component
我们关于组件的故事
How storybook show stories to us
故事书如何向我们展示故事
Developing your components in isolation from the working environment is not only a plus to the purity of the components, but it will also allow you to immediately see which states are not covered by the tests, and which, in principle, are absent.
与工作环境隔离地开发组件不仅可以提高组件的纯度，而且还可以使您立即查看测试未涵盖哪些状态，以及原则上不存在哪些状态。
But in the end, this also will not give us everything that we want.
但是最后，这也不会给我们我们想要的一切。
Therefore, only one thing remains.
因此，只剩下一件事。
测试和快照 (Tests and Snapshots)
Since our components are atoms and molecules, it becomes a pleasure to write unit tests, each component is responsible for one functionality that we can easily test by discarding several items from the list of recommendations at once.
由于我们的组件是原子和分子，因此编写单元测试变得很高兴，每个组件都负责一种功能，我们可以通过一次丢弃建议列表中的几项来轻松地进行测试。
We can set up snapshot checks, which will allow us to monitor the state of our components and to learn all the changes in the future.
我们可以设置快照检查，这将使我们能够监视组件的状态并了解将来的所有更改。
We can use a bundle with an enzyme to control our expectations during development. And strangely enough, when it comes to recommendations in which we expect something from a developer who writes code, only tests and their writing can best suit. They were literally invented for this.
在开发过程中，我们可以将束与酶结合使用来控制我们的期望。 奇怪的是，在建议中，我们期望编写代码的开发人员有所帮助，只有测试及其编写才最适合。 他们实际上是为此发明的。
And here we go…
现在我们开始…
Write tests for your components. Thanks.
为您的组件编写测试。 谢谢。
ipad ui kit
2852
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
