Привет. Меня зовут Сергей Сова.
Я наконец-то сделал канал о том, как я негодую... о нашем фронтенде.
На самом деле писать буду о разработке в целом.
Я наконец-то сделал канал о том, как я негодую... о нашем фронтенде.
На самом деле писать буду о разработке в целом.
Почему @AtomicDesign спасет вашу душу.
Некоторые считают, что этот подход слишком заморочен. Заставляет много думать о расположении элементов, а при усложнении - перемещать его в другие директории. Если спросить Родионова - найдется ещё несколько причин, почему не надо использовать Atomic Design. В этом посте я хочу рассказать об обратном: как использовать подход Брэда Фроста в React.
В самом начале необходимо понять - нужен ли вашей команде этот архитектурный дизайн. Достаточно ответить на следующие вопросы:
- сколько человек будут разрабатывать фронтенд?
- сколько команд будут использовать ваш код?
- сколько проектов используют один UI дизайн?
Если у вас один небольшой проект, в котором всего два фронтендера - вам не нужен AtomicDesign. Если в вашем проекте около 10 фронтендеров и намечается второй проект - нужно задуматься о внедрении AtomicDesign. Тем более если в вашей компании проекты используют общую библиотеку компонентов или планируется внедрение.
Многие задают мне один и тот же вопрос: "Куда положить компонент X?". Отвечаю сразу для всех компонентов: AtomicDesign - это подход, обеспечивающий вам архитектуру UI компонентов - не более. То есть контейнеры/коннекторы/роутеры вы можете класть в любую директорию, кроме ui. Я всегда рекомендую начать изучение с прочтения книги автора atomicdesign.bradfrost.com, но ниже немного опишу составные части.
Сразу следует понять, что компоненты AtomicDesign — это бизнес-сущности, это то, чем могут оперировать дизайнеры и разработчики вместе. Не надо включать сюда различные таймеры появления блоков или логику переключения вкладок. Пусть даже они у вас описаны в виде компонентов или HOC'ов.
Так почему это все спасает души? Чтобы понять ответ, обратимся к ещё одной теме фронтенда: типизированный javascript. Typescript/Flowtype придумали для наложения определенных ограничений на код, чтобы в дальнейшем его было проще поддерживать и читать. AtomicDesign накладывает ограничения на дизайнеров и фронтендеров, обязывая их общаться на одном языке бизнес-сущностей.
Но необходимо добавить несколько слов о поддержке библиотеки компонентов AtomicKit. В какой-то момент возникает проблема усложнения компонентов, и многие задаются вопросом: "Как же быть, неужели теперь нужно перемещать компонент из атомов в молекулы?" — Нет.
Перед стартом разработки необходимо тщательно проектировать набор компонентов и не менять его предназначения, пока он существует под таким названием. Если же вам необходимо усложнить компонент, добавить в него какие-то элементы - просто создайте ещё один компонент, который будет добавлять то, что вам нужно. Так вы не сломаете совместимость со всей библиотекой и реализуете необходимую вам функциональность. Во время создания второго компонента следует помнить о композиции и рекомендации DRY: не надо копипастить, достаточно использовать уже существующие компоненты.
Некоторые считают, что этот подход слишком заморочен. Заставляет много думать о расположении элементов, а при усложнении - перемещать его в другие директории. Если спросить Родионова - найдется ещё несколько причин, почему не надо использовать Atomic Design. В этом посте я хочу рассказать об обратном: как использовать подход Брэда Фроста в React.
В самом начале необходимо понять - нужен ли вашей команде этот архитектурный дизайн. Достаточно ответить на следующие вопросы:
- сколько человек будут разрабатывать фронтенд?
- сколько команд будут использовать ваш код?
- сколько проектов используют один UI дизайн?
Если у вас один небольшой проект, в котором всего два фронтендера - вам не нужен AtomicDesign. Если в вашем проекте около 10 фронтендеров и намечается второй проект - нужно задуматься о внедрении AtomicDesign. Тем более если в вашей компании проекты используют общую библиотеку компонентов или планируется внедрение.
Многие задают мне один и тот же вопрос: "Куда положить компонент X?". Отвечаю сразу для всех компонентов: AtomicDesign - это подход, обеспечивающий вам архитектуру UI компонентов - не более. То есть контейнеры/коннекторы/роутеры вы можете класть в любую директорию, кроме ui. Я всегда рекомендую начать изучение с прочтения книги автора atomicdesign.bradfrost.com, но ниже немного опишу составные части.
Сразу следует понять, что компоненты AtomicDesign — это бизнес-сущности, это то, чем могут оперировать дизайнеры и разработчики вместе. Не надо включать сюда различные таймеры появления блоков или логику переключения вкладок. Пусть даже они у вас описаны в виде компонентов или HOC'ов.
Так почему это все спасает души? Чтобы понять ответ, обратимся к ещё одной теме фронтенда: типизированный javascript. Typescript/Flowtype придумали для наложения определенных ограничений на код, чтобы в дальнейшем его было проще поддерживать и читать. AtomicDesign накладывает ограничения на дизайнеров и фронтендеров, обязывая их общаться на одном языке бизнес-сущностей.
Но необходимо добавить несколько слов о поддержке библиотеки компонентов AtomicKit. В какой-то момент возникает проблема усложнения компонентов, и многие задаются вопросом: "Как же быть, неужели теперь нужно перемещать компонент из атомов в молекулы?" — Нет.
Перед стартом разработки необходимо тщательно проектировать набор компонентов и не менять его предназначения, пока он существует под таким названием. Если же вам необходимо усложнить компонент, добавить в него какие-то элементы - просто создайте ещё один компонент, который будет добавлять то, что вам нужно. Так вы не сломаете совместимость со всей библиотекой и реализуете необходимую вам функциональность. Во время создания второго компонента следует помнить о композиции и рекомендации DRY: не надо копипастить, достаточно использовать уже существующие компоненты.
Атомы — простейшие компоненты, составляющие части более высокоуровневых компонентов. Могут включать в себя: чистый html, стили. Не могут: состоять из других атомов, иметь логику отображения. Например: поле ввода, подпись, графический значок.
Молекулы — составные компоненты, отражающие одну бизнес-сущность. Могут включать: атомы, html, стили, несложную логику. Не могут включать в себя: другие молекулы, сложную логику, иметь неопределенное поведение. Например: поля форм, заголовки, вкладки, полоса прогресса. Молекулы, как и атомы должны быть максимально универсальными.
Организмы — компоненты, имеющие сложную логику. Самые используемые компоненты в вашем проекте. Содержат в себе: атомы, молекулы, сложную логику и в некоторых случаях поведение, определяющееся извне. Необходимо избегать использования непосредственно стилей в организмах, для этого есть более низкоуровневые компоненты. Например: форма регистрации, карточка статьи, календарь, чат.
Шаблон — разметка для других компонентов. В некоторых случаях у вас будут компоненты, которые просто размещают в себе другие компоненты в определенных местах, - это и есть шаблоны. Шаблоны упростят жизнь, если у вас есть некая разметка с простыми стилями и позиционными компонентами. Может включать в себя: атомы, молекулы, стили, другие шаблоны, простейшую логику. Не может включать в себя: организмы. Шаблоны могут быть как целой страницы, так и её частей. Например: шаблон страницы пользователя/компании, шаблон заголовка сайта (Header).
Страницы — компонент, включащий в себя все остальные компоненты, конечная точка вашего роутера. Страницы обычно располагаются в проекте, используя компоненты из библиотеки.
Экосистемы — наборы компонентов, связанных одной областью использования. Обычно это вложенная директория с той же структурой atoms, molecules, organisms, включающая в себя только компоненты. Которые, например, относятся только к профилю пользователя. При составлении UI библиотеки экосистемы скорее всего останутся в проекте, а в библиотеку уйдут универсальные для всех проектов компоненты.
Молекулы — составные компоненты, отражающие одну бизнес-сущность. Могут включать: атомы, html, стили, несложную логику. Не могут включать в себя: другие молекулы, сложную логику, иметь неопределенное поведение. Например: поля форм, заголовки, вкладки, полоса прогресса. Молекулы, как и атомы должны быть максимально универсальными.
Организмы — компоненты, имеющие сложную логику. Самые используемые компоненты в вашем проекте. Содержат в себе: атомы, молекулы, сложную логику и в некоторых случаях поведение, определяющееся извне. Необходимо избегать использования непосредственно стилей в организмах, для этого есть более низкоуровневые компоненты. Например: форма регистрации, карточка статьи, календарь, чат.
Шаблон — разметка для других компонентов. В некоторых случаях у вас будут компоненты, которые просто размещают в себе другие компоненты в определенных местах, - это и есть шаблоны. Шаблоны упростят жизнь, если у вас есть некая разметка с простыми стилями и позиционными компонентами. Может включать в себя: атомы, молекулы, стили, другие шаблоны, простейшую логику. Не может включать в себя: организмы. Шаблоны могут быть как целой страницы, так и её частей. Например: шаблон страницы пользователя/компании, шаблон заголовка сайта (Header).
Страницы — компонент, включащий в себя все остальные компоненты, конечная точка вашего роутера. Страницы обычно располагаются в проекте, используя компоненты из библиотеки.
Экосистемы — наборы компонентов, связанных одной областью использования. Обычно это вложенная директория с той же структурой atoms, molecules, organisms, включающая в себя только компоненты. Которые, например, относятся только к профилю пользователя. При составлении UI библиотеки экосистемы скорее всего останутся в проекте, а в библиотеку уйдут универсальные для всех проектов компоненты.