Архитектура FE-части приложения на основе Atomic Design
Решили поделиться с вами одним из решений для создания масштабируемой архитектуры монолитного приложения, которое применяли сами. Метод дает возможность минимизировать накладные расходы на тестирование с разрастанием проекта. А также снижает шансы появления багов в процессе доработки проекта в связи с изменениями требований заказчика.
Мы не претендуем на статус Колумба – для кого-то этот материал не будет открытием, но для кого-то может быть и полезен.
Метод достаточно прост, поэтому статья будет полезна:
- мидлам, чтобы освежить память;
- джунам для работы как на внутренних, так и внешних проектах компании;
- руководителям проектов для быстрого принятия решения о составе проектной команды.
Задачи, решаемые с помощью данного подхода:
- максимально быстрое и простое понимание проекта в случае подключения новых людей к проекту;
- максимальное переиспользование компонентов;
- безопасное легкое и быстрое изменение уже написанного функционала на поздних этапах проекта;
- легкое расширение проекта людьми, незнакомыми с предметной областью.
Схема взаимодействия компонентов в нашем опыте выглядела так:
В соответствии с atomic design, декомпозиция компонентов выглядит так:
атомы -> молекулы -> организмы -> темплейты -> страницы
Для более простого понимания структуры каждого конкретного компонента нами было принято решение разделить всю логику, в том числе сетевые запросы, и инициализацию модулей хранилища по принципу Atomic Design, т.е. каждый модуль содержит в себе все необходимое для его работы.
Пример файловой структуры компонента:
- Logic – содержит логику компонента;
- Reducers – часть глобального стора, относящаяся к этому компоненту, методы для работы с данной частью стора;
- Request – часть, отвечающая за логику сетевого взаимодействия;
- UI – отвечает за отображение компонента.
Для реализации данного подхода организации логики был выбран пакет Redux-toolkit, в котором есть очень удобный функционал для «нарезки» стора и функций запросов без излишнего бойлерплейт-кода, с помощью слайсинга логики на подмодули.
Ознакомившись с README, разработчик, который даже не знаком с проектом и предметной областью, может легко найти компонент, отвечающий конкретно за его задачу, поправить его или добавить новый.
Сетевые запросы были приоритезированны, и ожидалось, что вся сетевая логика, необходимая для загрузки страницы, осуществлялась на самом верху страницы, но в некоторых ситуациях была возможность написать сетевую логику в компонентах, находящихся ниже в структурной иерархии, во избежание большого Prop Drilling.
Например, компонент поиска в Elasticsearch работает независимо от страницы и должен обеспечивать поиск вне зависимости от места применения.
Данный подход наложил некоторый отпечаток на процесс написания тестов. Тесты писали по восходящему принципу, сначала покрывались тестами компоненты нижнего уровня (атомы), а компоненты верхнего уровня (страницы) покрывались в последнюю очередь.
За счет разделения компонентов на составляющие, удалось добиться того, что один unit-тест проверяет только одну составляющую компонента (UI, запросы, логику, стор).
На каждый компонент добавлялись интеграционные тесты, которые показывали, что при правильных данных во всех составляющих компонента, на выходе отрисовывается правильный компонент. Таким образом обеспечивалась минимальная проверка «совместимости» всех модулей компонента между собой.
Процесс добавления компонента был организован следующим образом:
- 1 этап: написание компонента и тестов, покрывающих все модули компонента;
- 2 этап: ручное тестирование компонента;
- 3 этап: написание тестов на непокрытые кейсы или обнаруженные ошибки;
- 4 этап: исправление компонента.
Так нам удалось добиться того, что уже протестированные компоненты работали ожидаемо даже при изменении сторонних зависимостей.
Так как данные в разных компонентах получались от разных микросервисов с BE, было необходимо обеспечить функционирование тех компонентов, BE-часть для которых работает некорректно.
Каждый компонент имел свой собственный статус «включено», «отключено», «ошибка», за который отвечал отдельный errorBounday и, в случае ошибки или отключения компонента, блокировал его работу.
Было полезно? Будем рады получить обратную связь или узнать какой подход использовали вы при подключении команды или ее части на поздней стадии проекта ✌
Молодёжь ведётся на всё модное. И глупое.
Зачем компонент называть молекулой? Или атомом? Просто по чьему-то субъективному мнению, мол этот большой, а этот маленький? А если у другого разработчика другое мнение?
Короче, обозвали зачем-то компоненты по новому и заявляют - это новый подход к проектированию!
Дедушка, позвольте молодежи сказать пару слов)
<= "Короче, обозвали зачем-то компоненты по новому и заявляют - это новый подход к проектированию!"
=> А то вы прям накидываете так, что лопатой не раскидаешь, в тексте нет ни слова, о новизне)
<= "Зачем компонент называть молекулой? Или атомом? Просто по чьему-то субъективному мнению, мол этот большой, а этот маленький? А если у другого разработчика другое мнение?"
=> Данный подход основан на системе, которая иногда используется дизайнерами и которая наиболее близка к дизайн системе)
Ситуация когда другой разработчик подумает по другому, очень легко решается после изучения темы и подходов atomic design, в гугл не посылаю, отдаю сразу первоисточник, ссылочка ниже.
Ну и да, речь не про размер компонента, а про его роль, что вы, конечно же, бы знали после изучения темы.
https://bradfrost.com/blog/post/atomic-web-design/
Не туда