Comments 15
Из своего опыта: лучше сводить архитектуру к библиотеко-ориентированному подходу. Каждая библиотека представляет собой независимый модуль, требует соответствующего подхода разработки. Т. Е. мы имеем дело с чёрным ящиком. Пользователь библиотеки не заботится о внутреннем устройстве, качество руки програмиста, что писал код. Его заботит лишь интерфейс и гибкость управления им. Ещё неоспоримым преимуществом этого подхода - максимальная готовность кода. Сборка проекта внутренних компонентов может съедать много времени. У меня есть пример холодной сборки в dev режиме angular-cli 5 минут. На prod 20 минут. А так, архитектуру подбирают под требования.
Спасибо за комментарий) Да, это идеальный вариант. С каждым новым проектом такие библиотеки у нас либо появляются, либо дорабатываются при необходимости.
вот не знаю, сколько не пытаюсь, но не получается сделать компонентную архитектуру, даже если есть похожие блоки, они потом обрастают кучей пропсов, чтобы можно было использовать в двух случаях каких то, не говоря уже о трех и более, поэтому пока в поиске идеальной архитектуры для фронта. и да, опыт и на React'е и на Vue и другими менее известными аналогами, есть и там и там проблема с этим.
В $mol и его аналогах такой проблемы нет в принципе.
➖ Фронтендер, расскажи что-нибудь про архитектуру.
➖ Файлы можно класть так, а можно сяк.
---
Это подсмотрено у Эрика Эванса (Domain Driven Design): domain, store, ui.
Вот на бекенде становится быстро понятно, что домен не должен зависеть от инфраструктуры: тестировать неудобно. А в последнем варианте тестирование домена не предполагается или только e2e вместе с бекендом?
Спасибо за комментарий) Тестирование домена можно проводить отдельно от инфраструктуры. За все внешние взаимодействия отвечает отдельный инфраструктурный слой, который можно замокать при тестировании домена
Так-то, конечно можно, но на практике это муторно и быстро устаревает. В тестовых проектах пробую отдельный инфраструктурный слой, который слушает изменения домена. Когда появляется сущность с условно `isFetching: true` вызывает get/put/post нужный. В тестах просто этот слой не подключается.
Но в нормальном проекте еще не пробовал, так что интересно, заведется или нет.
От архитектуры только слова, зато как папки разложить - миллион скриншотов. Обидно
Недавно наткнулся на видео на ту же тему, что и ваша статья
https://www.youtube.com/watch?v=c3JGBdxfYcU
У меня вопросы:
С каких пор во фронтенде архитектурой стали называть организацию структуры папок в проекте?
"Components, Store, Containers", "Feature Oriented" - откуда взяты такие названия для подходов?
Какое-то сильно громкое слово "архитектура" для фронтенда. Фронтенд - это всего-лишь view слой всей архитектуры всего приложения\системы вцелом. И относится к этому view-слою нужно проще, т.е. не городить лишних абстракций ещё и в нём , и не дробить его ещё больше (аля, бизнес\не бизнес логика, а в друг в будущем придётся переписать на другой фреймворк, и т.д.).
Да, ui-логика внутри может быть сколь угодно сложная, динамичная и запутанная. Но настоящия бизнес логика, настоящие состояния, транзакции и прочее - это всё на бекенде.
P.S. чтобы "архитектура" фронтенда не обосралась через полгода - верю в удтверждение что "на фронт-проекте должно быть максимум три разработчика, при чём главный - только один". Какая бы скорость разработьки не требовалась - не более 3-х человек на проект!
А что "чистую (гексагональную) архитектуру" с бэкенда совсем неполучается натянуть на фронтенд?
Там ведь не настолько порог входа высок, да и с TS должно быть удобно ее имплементировать. Ядро и сущности огороженные портами-интерфейсами, адаптеры для веба, локалстораджа итд. Ну и мапперы между слоями. В Ангуляре вроде даже инжектить зависимости можно, ну или просто ядро сделать отдельным нпм модулем.
Архитектура front-end приложений — react, react native, angular. Обзор