Reputation: 281
I have read a lot of articles regarding this subject, but am still having trouble processing that matter. Sorry if it is a duplicate, regardless!
So basically, I am building an Angular app from scratch, and I want to organize my code as per the best convention. I have a core module, that currently includes a generic data access singleton service, and an auth service that uses it. What I can't grasp is, when should I make a feature module, and when that functionality belongs to the core module.
Core Module tree:
Auth, for example, sounds like app core, but in my case it would also include some declarations (components, etc.), and would probably need to import some UI atoms/molecules from a shared module. Does it deserve a feature module, imported directly in the root module? Should I let the core module export the auth module's declarations? Or should I separate the providers for auth (core module) and make another auth feature module (for the declarations)?
Same goes for layout module, modal module, etc.
Thanks!
Upvotes: 9
Views: 9813
Reputation: 2076
For small size app, you need not to consider this. But if the app is large enough, you can modularize your app.
For large apps with lots of routes, you may consider lazy loading. Lazy loading will help keep initial bundle size smaller, that means only core module will be loaded at first when the app get loaded. It will reduce initial loading time of your app.
Core Module
You may put the following items in core module (you may put others if you see fit).
To guard against re-importing of core module by other feature module, you can add the following constructor in CoreModule:
constructor(@Optional() @SkipSelf() parentModule: CoreModule) {
if (parentModule) {
throw new Error(
'CoreModule is already loaded. Import it in the AppModule only.');
}
}
Shared Module
Feature Module
Declare models, components, services and other items that will be only used within this module.
And for each feature module, you can also create a routing module.
Upvotes: 26