Вложенные модули плохи в Angular?

Вложенные или не вложенные - это не черно-белая ситуация. К сожалению, как и в большинстве случаев разработки программного обеспечения, «это зависит от обстоятельств».

Тем не менее, я призываю вас обдумать это - суть NgModule (помимо технической мотивации для разрешения AOT) состоит в том, чтобы предоставить «единицу» более высокого уровня для вашего приложения. Другими словами, вы можете сгруппировать отдельные компоненты / службы / каналы в дискретные группы, которые позволят вам рассматривать эту группировку как единое целое, обеспечивающее определенную функциональность. В большинстве случаев это используется для обеспечения функций в вашем приложении (так называемых «функциональных модулей»), но система NgModule также используется для решения других типов сквозных проблем. Фактически, авторам библиотек становится легко распространять свою библиотеку как единый модуль NgModule, инкапсулирующий все предоставляемые ими функциональные возможности. (Примеры включают встроенные библиотеки, такие как HttpModule и FormsModule, а также MaterialModule, FlexLayoutModule и т. Д.)

Этот пример использования NgModule как контейнера распространения помогает мне подумать о том, как я должен сгруппировать свои компоненты / службы / каналы - это не всегда возможно, но я стараюсь думать, что могу взять папку, содержащую определение модуля и его различные части. и должен иметь возможность перетащить эту папку в любое другое приложение, и оно должно в основном работать (при условии наличия его внешних зависимостей). Такой подход помогает мне сосредоточиться на том, насколько детально сделать NgModule. Это не значит, что я не вкладываю папки в этот NgModule, но то, что есть вложенная папка, не означает, что я автоматически создаю NgModule - если эти элементы не имеют смысла в качестве какого-либо контейнера распространения, я не буду беспокоиться для создания вложенных модулей NgModules в соответствии со структурой папок.

Подводя итог, ваша структура папок не означает, что вы автоматически создаете NgModules для глубоко вложенных папок - и поэтому, вероятно, нет необходимости в глубоко вложенной настройке NgModule.

Для меня основная цель использования NgModules - это ленивая загрузка; Я не поклонник логического / функционального структурирования в angular. Если бы в angular не было ленивой загрузки, я бы, вероятно, просто структурировал код следующим образом:

components/
services/
pipes/
models/
...

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

Итак, в настоящее время я структурирую свой код следующим образом:

app
|
 --services/
   |
    -- the services module called `CoreModule` in angular docs.
 --shared/
   |
    -- the shared module described in angular docs. Has models as well.
 --pages/
   |
    -- page1/
       |
        -- a module for page1/feature1 that I'll use in lazy-loaded manner (but may not do so if found unsuitable).
    -- page2/
       |
        -- a module for page2/feature2 that ...

Итак, отвечая на ваш вопрос конкретно о вложенности:

• Вложенные модули на самом деле представляют собой просто структуру папок; нет никакого эффекта против отсутствия тестирования по углу. Вложенный модуль похож на модуль верхнего уровня. Например, вы можете импортировать login.module.ts в модуль рядом с dashboard.
• Поскольку это структура папок, нет ограничений на уровни вложенности по углу.
• Однако обычно во вложенных модулях у вас есть модуль X, импортирующий модуль Y, импортирующий модуль Z, ... и т.д. На данный момент я не знаю, влияет ли это на производительность или нет, но я не ожидаю, что это имеют. Тем более, что такая же ситуация существует в зависимостях библиотек: создание изображений с использованием компонента / модуля angular из некоторого пакета npm, который использует другой компонент / модуль angular в другом пакете npm и т. Д.
• Что касается моего мнения о вложенных модулях и структуре кода в целом, я изложил его выше.

Чтобы избежать вложенности, см. Принцип «Сохраняйте плоскую структуру папок как можно дольше» в Официальное руководство по стилю Angular. В общем, Руководство по стилю кажется хорошим местом для подобных вопросов (только что открыл его!).