Модули: когда и почему?

Ответ 1

В конечном итоге концепция модуля пришла к Angular 2 из-за необходимости ленивой загрузки. Там должно быть единственное место, где могут быть объявлены зависимости раздела одного приложения и предоставлены сервисы.

В результате мое предпочтение в общем состоит в том, чтобы разделить приложение на модули только так, как это необходимо для обеспечения ленивой загрузки. Лично я нахожу больше заявлений модулей ограниченного использования.

Тем не менее, нет единственной лучшей практики в отношении модулей. Большая часть из них зависит от проекта. Некоторые разработчики предпочитают создавать модуль для каждого компонента, в то время как другие имеют один модуль для всего своего приложения.

В пользу использования большого количества модулей: существует несколько недостатков для создания этих модулей, отличных от многословности кода. У вас будут небольшие разделы вашего приложения, которые можно легко переустановить и перенести в другие приложения. Зависимости для определенных областей вашего приложения также более явны (вместо того, чтобы все директивы вашего приложения были доступны для всех компонентов).

В пользу использования небольшого количества модулей:, вы потратите меньше времени, пытаясь объявить компоненты, совместно используемые между модулями. Один корневой модуль, содержащий все объявления вашего компонента, является единственным источником правды для зависимостей вашего приложения.

В общем, я бы сказал, иди со своей кишкой. Выбор создания модуля не так сильно отличается от выбора для создания новой папки в приложении. Если вы обнаружите, что вам неудобно размер и объем модуля, стоимость рефакторинга минимальна.

Ответ 2

Угловое руководство по стилю обсуждает тему, когда использовать модули. Ссылка на структуру приложения и раздел NgModules. Еще лучше, посмотрите этот заголовок, чтобы перейти непосредственно к обсуждению модулей. Я суммировал некоторые детали ниже, но есть детали, которые я пропустил, чтобы мой ответ не был слишком длинным. Используйте его, чтобы почувствовать, но, пожалуйста, обратитесь к руководству по стилю для полного контекста.

корень

Создайте NgModule в корневой папке приложения, например, в /src/app.

Зачем? Каждое приложение требует как минимум один корневой NgModule.

Характеристики

Создайте NgModule для каждой функциональной области.

Зачем? NgModules упрощают загрузку маршрутизируемых функций.

Зачем? Модули Ng облегчают изоляцию, тестирование и повторное использование функций.

Общий

Создайте функциональный модуль с именем SharedModule в общей папке; например, app/shared/shared.module.ts определяет SharedModule.

Объявите компоненты, директивы и каналы в общем модуле, когда эти элементы будут повторно использоваться и на них будут ссылаться компоненты, объявленные в других функциональных модулях.

Попробуйте использовать имя SharedModule, когда на содержимое общего модуля ссылаются во всем приложении.

Зачем? SharedModule будет содержать компоненты, директивы и каналы, которым могут понадобиться функции из другого общего модуля; например, ngFor в CommonModule.

ядро

Подумайте о том, чтобы собрать множество вспомогательных одноразовых классов внутри основного модуля, чтобы упростить кажущуюся структуру функционального модуля.

Подумайте о вызове основного модуля всего приложения, CoreModule. Импорт CoreModule в корневой AppModule уменьшает его сложность и подчеркивает его роль в качестве организатора приложения в целом.

Создайте функциональный модуль с именем CoreModule в основной папке (например, app/core/core.module.ts определяет CoreModule).

Поместите одиночный сервис, экземпляр которого будет совместно использоваться в приложении в CoreModule (например, ExceptionService и LoggerService).

Импортируйте все модули, необходимые для ресурсов в CoreModule (например, CommonModule и FormsModule).

Зачем? CoreModule предоставляет один или несколько одноэлементных сервисов. Angular регистрирует провайдеров с помощью корневого инжектора приложения, делая одноэлементный экземпляр каждой службы доступным для любого компонента, который в них нуждается, независимо от того, загружен ли этот компонент быстро или лениво.

Зачем? CoreModule будет содержать одноэлементные сервисы. Когда их загружает ленивый загруженный модуль, он получает новый экземпляр, а не предполагаемый синглтон для всего приложения.

Соберите одноразовые компоненты для всего приложения в CoreModule. Импортируйте его один раз (в AppModule) при запуске приложения и никогда не импортируйте в другое место. (например, NavComponent и SpinnerComponent).

Зачем? Реальные приложения могут иметь несколько одноразовых компонентов (например, счетчики, тосты сообщений и модальные диалоговые окна), которые появляются только в шаблоне AppComponent. Они не импортируются в других местах, поэтому они не являются общими в этом смысле. Тем не менее, они слишком большие и грязные, чтобы оставлять их в корневой папке.

Ответ 3

С JavaScript всегда существует проблема пространств имен.

Angular 1 имеет модули, которые помогут нам организовать наш код и решить некоторые проблемы с именами.

TypeScript (Angular 2) также имеет модули, которые помогают убрать вещи из глобального пространства имен.

Существует много вариантов использования, где нам может понадобиться Angular 2 Module. Предположим, что приложение получает больше функций, мы можем сгруппировать эти функции в свои собственные функциональные модули. Мы можем даже определить общие или общие модули для кода, используемые несколькими модулями Angular. Это позволяет организовать код и обеспечивает связную единицу, которую мы можем установить, которую мы можем загрузить при запуске, или ленивая загрузка по мере необходимости. Это делает ваше приложение намного быстрее.