12

I'm working with a rather large Angular application and currently have all shared components and modules inside a Shared Module which I import whenever I need anything which it exports.

However I have some small feature-modules which only needs very few modules from the Shared Module, should I then increase the complexity and modularity of the architecture in order to just import the modules I need, even if they are imported elsewhere?

The Angular docs state that imported modules which have already been imported in another module is cached and not a problem, but what does that mean, does the app gets slower/bigger even so?

Example: Module 1 imports A, B, C. Module 2 imports A, C, D.

Is there a performance loss if I import A, B, C, D in both modules (e.g through a Shared module)?

rjdkolb
  • 8,217
  • 8
  • 57
  • 77
Jakob Segerslätt
  • 260
  • 2
  • 9
  • You loose the ability to split your application into lazy loaded parts. Ideally you'd create a module per feature and then import that feature module where you need it. Then when you later want to improve initial load time, you just load the modules lazily that are not required in the parts of the application that are shown in the initial load, and everything else falls in place easily. – Günter Zöchbauer Oct 18 '17 at 06:21
  • I have a bunch of lasy loaded modules which imports the shared module. But does these get faster if i just import A, B, C and not D? Even if D has been loaded previously in another module? – Jakob Segerslätt Oct 18 '17 at 06:33
  • There is no need to care about modules being imported multiple times in multiple places, Angular takes care of that as mentioned in the docs you quoted. The main problem is when you load big modules even when only small parts of it are actually used. – Günter Zöchbauer Oct 18 '17 at 06:38
  • Alright, so in conclussion. Take care in lazy modules and only import whats needed, in non-lazy modules, "barrel"-modules are fine. – Jakob Segerslätt Oct 18 '17 at 06:42
  • I think you should always have a module per feature. It can often change in unexpected ways what should be lazy loaded and then changing the module structure can be extremely cumbersome. You can then always build more coarse grained feature modules out of smaller feature modules, but always try to import as specific as possible. – Günter Zöchbauer Oct 18 '17 at 06:46

1 Answers1

11

Maybe. It depends on your app's structure.

If you're not using lazy-loading, you can follow the docs and it will not duplicate any code. The default chunks created with the original config's built of the angular-cli will produce a single scripts.bundle.js for your modules (among other chunks for other stuff).

Now, if you are using lazy-loading (as you said you are in the comments of your question), it will create a chunk for each lazy-loaded module and you should proceed with caution.

The angular-cli uses webpack to create these chunks and by the time of this comment, it will duplicate the imported modules (and 3rd party libraries!) on EVERY chunk that needs them.

This is a known issue and it has been partially addressed, but it's waiting for webpack to implement a feature that's needed to solve it.

Suggestion:

Create a SharedModule for each of your lazy-laoaded modules and import/declare only the things necessary for that module and use only this SharedModule. Do not import your main app's SharedModule from within a lazy-loaded module.

This will still duplicate modules needed by different chunks, but at least it won't add unnecessary modules where they are not needed.

And keep an eye on the issues linked above, so you know when you'd be able to avoid this workaround.

Cheers!

mattarau
  • 2,093
  • 1
  • 13
  • 20
  • Thanks, great answer. I'll keep an eye on those threads. As it is now, the dublication in lazy modules make me kinda negative about them as it is a great system in the non-lazy modules. – Jakob Segerslätt Oct 18 '17 at 08:45