Испанский перевод оригинальной статьи Колона Ферри @coly010 «Component-First Architecture with Angular and Standalone Components», опубликованной 23 декабря 2021 г.
Команда Angular недавно предоставила RFC (запрос на комментарии) по автономным компонентам. Это попытка сделать NgModules необязательным. Важно подчеркнуть, что модули не будут полностью устранены, поскольку многие приложения Angular основаны на NgModules.
По этой теме Манфред Штайер уже начал исследовать, как мы можем использовать ее в наших приложениях, чтобы узнать больше, вы можете ознакомиться с его серией статей: https://www.angulararchitects.io/en/aktuelles/angulars-future-without-ngmodules-part-2-what-does-that-mean-for-our-architecture/.
Декларативная маршрутизация
Я считаю, что лучшая архитектура, которой мы можем достичь при внедрении автономных компонентов, это основанная на декларативной маршрутизации.
Декларативная маршрутизация — это концепция, которую мы видели реализованной в таких пакетах, как react-router. Это означает объявление наших маршрутов как элементов в шаблоне нашего компонента.
В Angular у нас нет официально поддерживаемого решения для декларативной маршрутизации; однако Брэндон Робертс создал пакет, реализующий эту концепцию в Angular Component Router.
Angular Component Router позволяет нам определять маршруты через наше приложение в наших компонентах, избавляя нас от необходимости настраивать модуль RouterModule в нескольких уровнях или модулях нашего приложения.
Поскольку автономные компоненты требуют, чтобы мы указывали их импорт в декораторе @Component, это может стать громоздким. Это также означает, что мы все еще полагаемся на NgModules, что затрудняет их полное удаление из Angular.
Архитектура компонентного подхода
Что если мы просто используем наш шаблон компонента для определения маршрутов через наше приложение? Легко, мы могли бы иметь декларативный API для маршрутизации нашего приложения, который поддерживает перенаправления, откаты, ленивую загрузку компонентов (важный момент!) и защиту для маршрутов.
Это может пойти еще дальше. На данном этапе мы можем определить маршруты для любого компонента приложения, но увидеть полную конфигурацию маршрутизации приложения может быть непросто.
При использовании автономных компонентов мы должны разделить наше приложение по features или доменам, т.е. мы создадим структуру папок/рабочих пространств, в которой каждая feature будет иметь свою собственную папку/библиотеку, а в корне у нас будет route-entry, которая служит входом и будет содержать маршруты для этой части приложения. Примером структуры может быть:
Мы видим, что у нас есть route-entry домен/функция корня нашего приложения, который будет определять маршрутизацию для этой области приложения. Теперь каждый будет точно знать, где искать, когда ему нужно найти, отредактировать или добавить маршруты в систему.
Отсюда наша основная маршрутизация должна указывать только на RouteEntryComponents.
Следование этому шаблону с автономными компонентами означает, что наши компоненты являются главной основой наших приложений, как и должно быть.
На данный момент мы можем сказать, что Component-First Architecture — это архитектура, в которой наши компоненты определяют и управляют пользовательским опытом в нашем приложении. Все, что влияет на пользовательский опыт, должно обрабатываться через наши компоненты, поскольку именно с нашими компонентами взаимодействует пользователь.
Почему мы должны заботиться о Component-First?
Во-первых, важно отметить, что Component-First нацелен на создание архитектурного паттерна, который ставит компоненты в качестве источника истины в наших приложениях Angular.
В настоящее время NgModules действуют почти как оркестранты, соединяя приложение. Именно из NgModules мы создаем архитектуру AppModule -> FeatureModules -> SharedModules -> CoreModules.
Эта архитектура хороша, потому что она работает, она масштабируема, но не является ли она излишеством? Возможно.
Хотя ngModules представляет собой отличное разделение в структуре приложения, как CoreModules и SharedModules, но они часто сложны и трудны в сопровождении. Кроме того, SharedModules, в частности, может стать ящиком бедствия, куда мы складываем все подряд, и это приводит к ситуации, когда нам нужно импортировать SharedModule во все наши FeatureModules, даже если нужна простая директива или один сервис.
В системе Component-First наши компоненты сами решают, что им нужно делать. Они могут внедрять зависимости через свой конструктор и могут импортировать любые компоненты, директивы или трубы, которые им необходимы для работы. Этот повышенный уровень детализации позволяет нашим компонентам сосредоточиться на своей функции, что уменьшает любые излишества, которые могут оказаться скомпилированными вместе с компонентом.
Еще один момент, который следует отметить, заключается в том, что компоненты в архитектуре Component-First полностью tree-shakeable, что означает, что если они не импортированы или не маршрутизированы, они не будут включены в конечный пакет наших приложений. В настоящее время для достижения того же эффекта с помощью NgModules мы можем использовать паттерн SCAM (Single Component Angular Module), который был популяризирован Ларсом Гирупом Бринк Нильсеном.
Следуя архитектурному паттерну Component-First, мы также уменьшаем связь между нашими компонентами и NgModules, что прокладывает путь к действительно свободной от NgModule Angular. Мы можем сохранить ту же композитность, которую обеспечивает NgModules, просто следуя некоторым лучшим практикам при организации нашего кода, к чему Angular уже хорошо привык.
Короче говоря, если компоненты указывают на компоненты, наша ментальная карта приложения становится проще, и мы можем увидеть структуру компонентов в нашем приложении и получить полную картину.
Мы перестанем беспокоиться о том, что NgModules добавляет дополнительные зависимости для ваших компонентов, которых вы можете не ожидать, потому что в Component-First наши компоненты диктуют свои собственные зависимости, и это значительно снижает кривую обучения и понимания нашего кода, когда кто-то новый приходит в команду.
Фото Olli Kilpi on Unsplash