#Shared modules in a large application (angular material)

1 messages · Page 1 of 1 (latest)

forest lotus
#

I've got a pretty large application with around 30 feature modules (a number of which are lazy-loaded), and a number of those modules use some of angular materials components. I've read a number of articles and asked chatGpt about the best approach when importing angular material into my feature modules and it doesn't seem clear which is the best approach:

  • Shared module - Import wherever needed. Will mean importing a lot of unused components into some feature modules. Ivy's tree-shaking should handle this for smaller bundle sizes for lazy loaded modules.
  • Import specific components into feature modules. - Import only what's needed. We can be more clinical but much more difficult to maintain.

What would people suggest is the best approach?

small moat
#

I would suggest not using modules at all and import the components/modules you need from each of the standalone components. But if you want to keep using NgModules, then yes, the best practie is to only import what you need in them.

forest lotus
#

I haven't really looked into standalone components all that much - are there any other benefits to this approach that you really like?

small moat
#

It makes it much easier to reuse components: you don't have to move them from one module to another when you want to use it in a new feature module. It also makes them easier to unit tests, most of the time.

serene hemlock
#

I think there's still a good argument to be made for the SharedModule pattern. There is a larger initial payload required to download the module, but it only has to be downloaded once.

If my understanding is correct: Feature modules without a SharedModule and standalone components redundantly bundle dependencies into every module that imports them -- so the cumulative size of the app would be larger.

forest lotus
#

So you're more in favor of having a MaterialSharedModule (for example) which imports a dozen components and then just importing that into feature modules? If I imported that in to 2 feature modules, would the material modules be added to both bundles?

fringe swift
#

@forest lotus
Even in case of standalone components you still need to import on every module along with shared module however the advantage i see is that feature module which doesn't require certain components will not be utilized but as you said "import only whats needed" would be difficult to maintain IMHO.

But i think if i had to approch this problem i would create multiple modules e.g
MatSharedModule, CommonModule etc and similar to that extracting out into smaller modules and import where as needed.

But i agree and see your concern that it would might be importing unnecessary components that might not needed in certain feature modules BUT my only point to splitting into multiple modules would be

  • Code Mainatainance
  • Add/Subtract from single module
  • Having more modularize code.

🤔 But i am not sure if it would be loaded once from bundles size POV or does importing in every feature module cost up an increase in bundle size.

Let me know your thoughts 🙂

serene hemlock
# forest lotus So you're more in favor of having a MaterialSharedModule (for example) which imp...

If vendorChunk is true in angular.json, a separate bundle should be created with third-party code -- the libs should not need to be re-downloaded for every component that needs them.

The bit of info I have not seen answered yet is whether standalone components benefit from vendorChunk optimization. If they don't, then I am happy to stick with a SharedModule. If they do, then I might rethink things.

forest flower