webpack обычно уже решает, как выборочно импортировать этот общий модуль handle-error.js или включать его в пакет общих ресурсов
Да, это верно и то же самое в Angular. Старайтесь не думать, что og NgModules имеет какое-либо отношение к пакетам веб-пакетов. Хотя верно, что ленивый модуль, определенный маршрутизатором, будет отображаться как отдельный пакет веб-пакета. Это чисто упаковочная стратегия, используемая компилятором Angular.
Так что мне интересно, что я потеряю, если просто импортирую handle-error.js в свои компоненты вместо того, чтобы обернуть его внутри @ngModule?
Примерно 25% моего исходного кода для проекта Angular сделано следующим образом.
Библиотеки, дополнительные классы, интерфейсы, функциональное программирование, утилиты и другие подобные вещи не обязательно должны быть в NgModule, если только вам не нужно использовать инжектор угловой зависимости.
В документации четко указано, что одной из основных целей модулей является ленивая загрузка. Так как handleError требуется только для страницы 2, не будет ли он загружен только после того, как запрошена страница 2?
И Angular, и Webpack не могут трясти код, основанный на динамическом использовании. В то время как веб-пакет может трясти дерево в зависимости от импортированного использования. Невозможно определить, была ли процедурная ссылка на глобальное определение типа.
Это особенно сложно в Angular из-за того, как работает инжектор зависимостей.
В результате представьте, что NgModule - это простой способ заявить Angular о том, что stuff используется в вашем проекте (компоненты, службы, поставщики и т. Д.).
Если другой модуль не ссылается ни на один модуль, то весь модуль можно удалить из сборки. Angular должен подходить к проблеме таким образом, поскольку он использует инжектор зависимостей во время выполнения.
Например;
const thing = injector.get(SOME_UNKNOWN_TOKEN);
В приведенном выше примере токен зависимости с именем SOME_UNKNOWN_TOKEN просит инжектор предоставить значение для thing.
Angular не может знать, кто, что или как был предоставлен SOME_UNKNOWN_TOKEN. Из какого модуля он поступил, кто отвечал за его предоставление и т. Д.
Так что он не может трясти дерево исключительно на основе импорта. Исходный код, который предоставляет thing, определенный SOME_UNKNOWN_TOKEN, возможно, не был импортирован ничем, напрямую связанным с исходным кодом Angular (вспомните сторонние библиотеки).
Я знаю, что это не дает прямого ответа на ваш вопрос, но это , почему мы используем модули вместо прямого импорта вещей. Было бы безопасно предположить, что Angular будет очень похож на React в том, как код связан, если у нас не было инжектора зависимостей.
Еще один вопрос: я должен также обернуть его в сервис? Хотя я уже, наверное, знаю ответ - это помогает на макетах для тестов
Это чисто решение, основанное на инжекторе зависимостей в Angular.
DI позволяет вам делать много специальных вещей, которые стоит изучить, потому что именно так может быть сделано множество соединений между компонентами. Компоненты также могут предоставлять свои собственные услуги и тому подобное.
Я не использую DI для сложных структур данных. Как дерево экземпляров объекта или где мне нужно создать много экземпляров вещи. DI идеально подходит для отдельных услуг, которые зависят от других услуг.