Современная архитектура фронтенда 101
Перевод статьи Modern Frontend Architecture 101. Это перевод первой статьи из трех.
Несколько недель назад мои коллеги backend разработчики заинтересовались нашей архитектурой, структурой кода и проблемами во frontend'е. После нескольких презентаций о том, как создавать масштабируемые и надежные приложения, я подумал, что было бы неплохо подвести итоги и поделиться нашей стратегией с сообществом.
Давайте начнем с просмотра типичной веб-страницы.
Обычный пользователь увидел бы вертикальную и горизонтальную панель инструментов, содержимое таблицы и диаграмму, в то время как для frontend разработчика существуют только компоненты (VBarComponent, HBarComponent, OverviewComponent, и т.д.).
Эти компоненты расположены в виде дерева, которое начинается с корневого узла (MainComponent, из диаграммы выше), обычно называемого главным компонентом. Каждое современное веб-приложение имеет хотя бы один главный компонент.
Это дерево является основой для компонентной архитектуры.
Далее мы увидим, как он управляет каждым аспектом frontend мира.
Анализируем дерево 🔎
Можно заметить, что компоненты, расположенные в одной ветке, работают вместе, предоставляя пользователю независимую и понятную деталь. Однако форма ветки может отличаться от одной фичи к другой, в зависимости от того, как она отображается и какую бизнес-задачу она решает.
Это различие делает структурирование кода более сложным, потому что, в отличие от серверной части, во frontend'е отсутствует стандартная n-уровневая архитектура для организации файлов приложения.
В данном случае решение должно быть обусловлено фичами, а не типом слоя. Каждая фича группирует свои компоненты внутри подпапки, что помогает разработчикам понять, куда добавить новый компонент, оставаясь гибким для любой возможной формы ветки.
AppRepo -- Overview * Фича Overview ---- Components * Папка с компонентами ------ ListComponent * Компонент списка ------ ChartComponent * Компонент диаграммы -- Details * Фича Details ---- Components * Папка с компонентами ------ SomeComponent * SomeComponent компонент ------ SomeOtherComponent * SomeOtherComponent компонент
Интуитивное решение 💥
Все это накладывает на нас некоторые ограничения. Что делать с техническими компонентами? Куда добавить общий компонент?
Здесь мы переходим от слова «фича» к чему-то более общему и менее связанному с функциональными областями, для этого я выбрал слово «кирпич». Зачем? На самом деле имеет смысл сказать, что мое приложение сделано из кирпичей. Каждый кирпич играет определенную роль, но вместе они составляют строительные блоки для приложения.
В этом примере мое приложение состоит из разных типов кирпичей:
- Ядро (Core): содержит в себе все необходимое для загрузки приложения. Он также предоставляет технические утилиты для других кирпичей (мониторинг, ведение логов, и т. д.)
- Общий (Shared): общие инструменты, виджеты, все, что используется во всех кирпичах. Например: всплывающие подсказки, диалоги ошибок, функции сортировки и т. д.
- Фичи 1, 2 и 3: фичи относящиеся к функциональному домену со специфичной добавленной значимостью для юзера.
- Фичи A, B и C: также являются кирпичами, но их добавленная значимость предназначена для фич, а не для приложения напрямую. Может быть расшарена между разными фичами (как в примере фичи А)
В этой статье мы увидели, как веб-страница может быть представлена в виде дерева компонентов. Эта древовидная форма объясняет, почему наша структура кода определяется фичами и как мы разбиваем наше приложение на разные блоки с уникальными ролями.
Послесловие
Подписывайся на нас в социальных сетях:
Vue.js
Nuxt.js
Наши друзья uWebDesign: