Мы использовали Atomic Design в качестве структуры проекта на производстве — как это было
Мы использовали Atomic Design в производстве. Я настоятельно рекомендую ознакомиться с Объяснение атомного дизайна Брэда Фроста, прежде чем читать это, особенно если вы не знаете, что такое атомный дизайн. Стоит отметить, что несмотря на то, что наша реализация в основном была сделана в реакции, стилизованных компонентах и тайпкрипте, Atomic можно реализовать на любой технологии.
Почему
Чтобы объяснить, почему мы выбрали Atomic, я хотел бы представить нашу проблему и пример использования.
- Компоненты должны совместно использоваться существующими приложениями (компоненты совместно используются ими).
- Компоненты должны были соответствовать критериям проектирования.
- Мы хотели создавать компоненты быстро.
- Библиотека должна находиться в собственном репозитории.
- Мы знали, что компонентов будет много (100+).
- Мы хотели создавать компоненты изолированно (сборник рассказов).
- Структура проекта и обозреватель компонентов должны быть удобными для навигации.
Нам нужно было выбрать структуру проекта, но большинство чертежей готовятся для целых приложений, а не только для библиотеки компонентов.
Наше бизнес-требование состояло в том, чтобы разделить его на базовые компоненты, такие как кнопки, элементы ввода, контейнеры и более сложные компоненты в соответствии с их функциями. Это неплохая идея, но может быть сложно придумать название, если в библиотеке более 100 компонентов. Просмотр таких библиотек тоже не самая простая задача, поэтому мы должны были помнить об этом.
Кроме того, организация по функциям была бы отличной, но в целом мы хотели, чтобы наши компоненты не знали о какой-либо бизнес-логике или требованиях. Сосредоточение внимания на том, что компонент должен делать в одно время, означало бы жертвы для любого будущего использования в другом сценарии.
Итак, мы начали думать… Может быть, это идеальный случай для использования Atomic Design? 🤔
За и против
Работая какое-то время с atomic, я начал замечать некоторые компромиссы. Как разработчики, мы можем только знать об этом, чтобы убедиться, что мы можем использовать это в своих интересах.
Плюсы
Легко ориентироваться
Мы описываем сложность компонентов, используя атомарный уровень, который говорит нам, насколько сложные компоненты используются внутри. Например, когда вы видите компонент формы с простыми входными данными, вы можете быть на 100% уверены, что это компонент уровня molecule в каталоге form.
Сложность бизнеса, описываемая дизайном
Вы можете сказать, насколько велики компоненты, не заглядывая в код. Если компонент представляет собой какую-то кнопку, это будет компонент-атом.
Поощряет разделение компонентов
Возможно, вам придется разделить компоненты или сгруппировать их, потому что вы можете использовать максимум 2 уровня ниже. Это заставляет вас взглянуть на другую похожую часть дизайна и создать компонент, который вы сможете повторно использовать позже.
Очень высокая возможность повторного использования
Поскольку вы разделяете свои компоненты, вы обнаружите, что часто их используете. Кроме того, вместо того, чтобы реализовывать другую аналогичную версию, вы добавите функциональность к существующей.
Тестирование
Как я описал выше, атомарность поощряет создание небольших компонентов, поэтому тестирование должно быть простым, если нам не приходится иметь дело с перегруженными организмами. Старайтесь, чтобы ваш тест был таким же изолированным, как ваш компонент, и тестируйте внешние функции также изолированно. Если вы хотите протестировать стиль, проверьте визуальное тестирование — используйте снимки.
Минусы
Вертикальное масштабирование ограничено
Мы можем становиться все больше и больше, но мы не можем становиться меньше, если что-то является атомом. Несколько раз с нами случалось, что некоторые компоненты атомов начинали иметь много логики (большинство реквизитов и стилей связаны). Подниматься по иерархии тоже не легче. Вы обнаружите множество семантических конфликтов, таких как молекула, импортирующая молекулу. Большинство этих проблем можно решить с помощью вариантов, но это похоже на уклонение от проблемы, а не на ее решение.
Новички будут в восторге
Новичкам придется понять, как создавать компоненты, которые случились с нами. Просто наберитесь терпения и просмотрите их ошибки (следите за семантикой на атомарном уровне).
Разделение компонентов может показаться дополнительной работой
Иногда это кажется ненужной работой, потому что вы просто объединяете несколько компонентов в более сложный, но это, как описано выше, упрощает навигацию по вашему проекту, а скорость разработки увеличивается с каждым разделением.
Несогласованные проекты трудно кодировать и поддерживать
Если вам нужно поддерживать N вариантов (например, ввод и кнопки), это может быть очень сложно и приведет к перегрузке атомов и молекул.
Что сложного
Сохранение атомов маленькими
Мы столкнулись с проблемой, когда атомы начали иметь много реквизита, но большинство из них были связаны со стилем. Реализация другого атома (например, кнопки, списка) с тем же кодом не кажется отличным решением. Мы принимаем решение о рестайлинге компонентов, изDescriptionList атома мы создали InlineHorizontalList, который был тем же компонентом, но стили обрабатывались по-разному. Это решило нашу проблему с перегруженным стилем, и мы по-прежнему сохраняем атомарный уровень.
Список описаний
Встроенный горизонтальный список
Организмы и страницы могут иметь много кода и реквизита.
Перемещение свойств стилей в варианты, так что в основном мы получаем версию компонента с измененным стилем. Мы можем опустить некоторые реквизиты, сделав это таким образом (мы пропустили большинство реквизитов, которые изменялись в этом варианте).
Более сложные компоненты могут нуждаться в большом количестве реквизитов для использования конечным пользователем. В этом случае проблема решилась перемещением свойств стиля и конфигурации в варианты и предоставлением им возможности использовать предварительно настроенные варианты. Еще одна вещь, которую мы можем сделать, — это обрабатывать очевидные сценарии, такие как использование локального управления состоянием (React’s useContext) или перемещение кода во внешние функции (например, React Hooks), где код является внешним по отношению к компоненту.
Реализация макетов
Реализация макетов без компонентов внутри поначалу кажется странной, потому что мы привыкли идти прямо на уровень страницы. Реализация макета может быть выполнена с использованием нескольких шаблонов, таких как named childsи props.
Самое сложное — это их разработка, потому что у нас не может быть реальных компонентов внутри. Вот почему мы решили создать для этого небольшой помощник, который использовался только для изолированного показа макета. Это был просто элемент div, который всегда заполнял родительский элемент, каждый элемент имел разный цвет границы, поэтому определить, когда заканчивается слот, было легко.
Помощник (белый мигает из-за перезагрузки), обратите внимание на изменение цвета границы
Что мы могли бы сделать лучше
Мы могли бы немного пожертвовать атомарной семантикой и приспособить ее к нашим потребностям. Также было бы полезно начать разделять код на варианты намного раньше. Со стороны библиотеки компонентов перемещать стили в варианты легко, но компоненты являются общими для разных проектов, поэтому лучше перестраховаться, чем сожалеть, так как запрос изменений во внешних, зависимых проектах может оказаться сложным.
Заключение
Atomic — это здорово, но далеко не идеальное решение. Для этого вам нужен конкретный вариант использования. (например, библиотека компонентов, несколько интерфейсов с общими компонентами).
Иногда разбить большие компоненты на более мелкие, соответствующие атомарной семантике, сложно, а испортить это больно при разработке. Глядя на это с другой точки зрения, это отличный инструмент проверки, который вы, вероятно, плохо справились с разделением дизайна на компоненты.
На мой взгляд, самым большим преимуществом является то, что атомарная разработка ощущается как быстрая на более позднем этапе цикла разработки, хотя начало может быть немного трудным. Создание компонентов без контекста способствует повторному использованию (это значительно ускоряет последующую разработку). Это было очень заметно для меня после работы с ним некоторое время.
Я настоятельно рекомендую использовать атомарность в качестве основы для создания собственной дизайн-системы, которая будет соответствовать вашим потребностям.
