0

Je travaille avec une application angulaire plutôt grande et j'ai actuellement tous les composants et modules partagés dans un module partagé que j'importe chaque fois que j'ai besoin de quelque chose qu'il exporte.Angular - L'importation de ngModules inutiles augmente-t-elle la taille des fichiers s'ils ont été importés ailleurs?

Cependant j'ai quelques petits modules qui n'ont besoin que de très peu de modules du module partagé, devrais-je alors augmenter la complexité et la modularité de l'architecture pour importer les modules dont j'ai besoin, même s'ils sont importés ailleurs ?

L'Angular docs state qui importait des modules qui ont déjà été importés dans un autre module est mis en cache et ne pose pas de problème, mais qu'est-ce que cela signifie, l'application devient-elle plus lente/plus grande?

Exemple: Module 1 importations A, B, C. Module 2 importations A, C, D.

est-il une perte de performance si j'importer A, B, C, D dans les deux modules (par exemple, à travers un module partagé)?

+0

Vous perdez la possibilité de diviser votre application en pièces chargées paresseuses. Idéalement, vous devez créer un module par entité, puis importer ce module de fonction là où vous en avez besoin.Ensuite, lorsque vous voulez améliorer le temps de chargement initial, il vous suffit de charger les modules paresseux qui ne sont pas nécessaires dans les parties de l'application qui sont affichées dans la charge initiale, et tout le reste se met facilement en place. –

+0

J'ai un tas de modules chargés lasy qui importent le module partagé. Mais cela devient-il plus rapide si j'importe juste A, B, C et non D? Même si D a déjà été chargé dans un autre module? –

+0

Il n'est pas nécessaire de se préoccuper des modules importés plusieurs fois à plusieurs endroits, Angular s'occupe de cela comme mentionné dans les documents que vous avez cités. Le problème principal est lorsque vous chargez de gros modules même lorsque seulement de petites parties sont réellement utilisées. –

Répondre

2

Peut-être. Cela dépend de la structure de votre application.

Si vous êtes sans utiliserlazy-loading, vous pouvez suivre les docs et il ne dupliquera aucun code. Le chunks par défaut créé avec la config originale construite de l'angulaire-cli produira un seul scripts.bundle.js pour vos modules (parmi d'autres morceaux pour d'autres choses).

Maintenant, si vous utilisez lazy-loading (comme vous avez dit que vous êtes dans les commentaires de votre question), il va créer un chunk pour chaque module chargé paresseux et vous devez procéder avec prudence.

La-cli angulaire utilise webpack pour créer ces morceaux et le temps de ce commentaire, il dupliquera les modules importés (et les bibliothèques 3ème partie!) Sur chaque morceau qui en a besoin.

Ceci est un known issue et il a été partially addressed, mais il attend webpack à implement a feature qui est nécessaire pour le résoudre.

Suggestion:

Créer une SharedModule pour chacun de vos modules laoaded paresseux et l'importation/déclarer que les choses nécessaires à ce module et utiliser uniquement ce SharedModule. N'importez pas le SharedModule de votre application principale à partir d'un module chargé par défaut.

Cela dupliquera toujours les modules requis par différents blocs, mais au moins, il n'ajoutera pas de modules inutiles là où ils ne sont pas nécessaires. Et gardez un œil sur les problèmes liés ci-dessus, de sorte que vous savez quand vous seriez en mesure d'éviter cette solution de contournement.

À la votre!

+0

Merci, bonne réponse. Je garderai un oeil sur ces discussions. Comme c'est le cas maintenant, la dublication dans les modules paresseux me rend un peu négatif à leur sujet car c'est un excellent système dans les modules non paresseux. –