Понимание иерархии компонентов

Обзор

Состав

├ Primitives
├ Elements
├ Compositions

Понимание иерархии

Основная цель иерархии - обеспечить сфокусированный объем ответственности для отдельных компонентов и значимых отношений между ними. Это позволяет составлять компоненты таким образом, чтобы обеспечить здоровый баланс структуры и гибкости. Без структуры компоненты становятся несовместимыми и несовместимыми. Но без гибкости компоненты становятся хрупкими и жестко ограниченными в использовании. Для здоровой библиотеки компонентов вам понадобится и то, и другое.

Если мы думаем о гибкости и структуре как о спектре, в этом масштабе будут жить разные типы компонентов. Примитивы в нижней части иерархии являются наиболее гибкими. По мере продвижения вверх по иерархии к элементам и композициям компоненты становятся менее гибкими и более структурированными. Это позволяет более конкретным, самоуверенным компонентам в вашей библиотеке быть согласованными, а также предоставляет место для компонентов более низкого уровня для сохранения их гибкости.

Но эти компоненты не существуют изолированно. Иерархия также устанавливает между ними значимые отношения. Элементы используются для создания элементов, которые составляются для создания композиций. Например, этот LeftNav - это композиция из Box примитива и элементов Nav, List, ListItem, Link.

Примечание. Эта композиция, скорее всего, возьмет опору, подобную элементам, и наложит на них карту для создания каждого ListItem, но, чтобы не усложнять пример, я пропустил это.

Эти отношения позволяют LeftNav быть самоуверенным экземпляром своей структуры. Однако, если нам нужно было создать другой экземпляр, который позволил бы Icons быть в паре с Links, мы могли бы скомпоновать примитивы и элементы вместо того, чтобы изменять этот экземпляр для его поддержки. Мы обеспечиваем гибкость и структуру за счет возможности комбинирования.

Примитивы

Примитивы - это наша компонентная абстракция самого нижнего уровня. Они ограничены только своей целью, нашими токенами и ценностями темы. Поскольку они настолько гибкие и могут быть объединены в множество различных элементов, их относительно немного. Они несут полную ответственность за визуальные проблемы. Они не думают о разных состояниях или поведении.

Во внутренней библиотеке вы захотите часто использовать примитивы для создания других элементов и композиций, но внешние потребители, скорее всего, не будут использовать их напрямую так часто, как другие компоненты. Чтобы понять почему, давайте рассмотрим пример Stack. Stack Композиция самоуверенного макета. Он существует, чтобы помочь создать вертикальный ритм (интервал) между элементами.

Используя Stack, его дочерний элемент Stack.Item и опору space, мы можем быстро создать равномерный интервал между каждым элементом. Но если это не сработает для нашего варианта использования, мы могли бы использовать элемент нижнего уровня, Flex, на котором он построен. Flex - это компонент макета, который знает о нашей шкале интервалов и о том, как использовать CSS Flexbox для выравнивания элементов. Скажем, вместо равномерного промежутка между всеми элементами нам нужно немного больше места вокруг среднего дочернего элемента.

Большой! Не так уж много работы. А если по какой-то причине нам понадобится еще больший контроль, мы могли бы использовать наш примитив самого низкого уровня, Box.

Примечание. Такая высокая степень настройки также предполагает необходимость их использования в гармонии с остальной частью библиотеки. У вас по-прежнему есть гарантии использования системных значений, но вы должны знать, как сохранить согласованность пользовательского интерфейса.

Элементы

Как и их химические аналоги, элементы нельзя разбить на более простую субстанцию ​​без потери своих основных характеристик. Они тесно связаны с элементами HTML, но не ограничиваются ими. Хотя они по-прежнему очень гибкие, они больше ограничены конкретным экземпляром. Некоторые из них имеют определенные варианты и состояния, но обычно не имеют поведения. Их можно использовать в различных контекстах, и они связаны только со своими собственными внутренними атрибутами. В приведенном выше примере LeftNav это элементы Nav, List, ListItem, Icon и Link. Вы также можете расширить Elements для создания более конкретных экземпляров. Например, у нас может быть NavLink, который активирует вариант, когда это текущий маршрут:

Композиции

Композиции - это наша компонентная абстракция самого высокого уровня. Они могут состоять из примитивов, элементов или, в некоторых случаях, других композиций. Хотя у них есть отдельные части, у них также есть связанное поведение. Вот некоторые примеры поведения: как и где появляется и исчезает всплывающее окно, как раскрывающееся меню реагирует на команды клавиатуры и как открывается и закрывается боковая панель. Такое поведение часто связано с состояниями (открыто, закрыто, наведение курсора, фокус и т. Д.) И атрибутами доступности. В идеале все эти поведения, состояния и атрибуты доступности также можно комбинировать. Это позволяет нам создавать раскрывающиеся меню, демонстрирующие то же поведение, что и наши всплывающие подсказки, даже несмотря на то, что пользовательский интерфейс полностью отличается. Вы можете создавать совершенно новые композиции с поведением из нескольких существующих композиций, чтобы они казались связными. Давайте добавим немного к нашему LeftNav примеру, приведенному ранее.

Заключение

Иерархия компонентов фокусирует сферу ответственности компонента, создает значимые отношения между компонентами, способствует компоновке и обеспечивает баланс между гибкостью и структурой в нашей библиотеке компонентов. Это дает внешним командам возможность более эффективно создавать и развивать свой пользовательский интерфейс и позволяет разработчикам более устойчиво поддерживать их.

часто задаваемые вопросы

Чем примитивы, элементы и композиции отличаются от атомов, молекул и организмов« Атомного дизайна ?

Для меня примитивы - это более низкий уровень, чем атомы AD, хотя я понимаю, что это субъективно. По сути, элементы - это атомы, а молекулы - это композиции. (Токены будут субатомными частицами, но мы можем поговорить об этом в другой раз.) Я также думаю, что все, что достаточно велико, чтобы считаться «Организмом», слишком велико, чтобы жить в библиотеке компонентов. Для этого имеет больше смысла жить в приложении продукта.

Различие между примитивами и элементами заключается в том, что элементы представляют собой один тип вещей (кнопка, значок, абзац и т. Д.), А примитивы могут быть разными типами вещей. Если мы хотим использовать клеточную аналогию: элементы - это клетки одного типа (кожа, мозг, кровь), а примитивы ближе к стволовым клеткам.