Is there a reason for the CoreModule pattern now that ProvideIn is an option?

Question

To my understanding the reason for a CoreModule was to have all the things necessary to initialize your application and also to hold services that were to be shared across all modules in the application (HttpInterceptors, AuthenticationService, etc). Now that we have provideIn: 'root', is there a reason to have a CoreModule anymore? Is this pattern now deprecated? Is there a use case where we still might want to have a CoreModule that holds all or some of the shared services?

Answer 1

You can checkout angular style guide: https://angular.io/guide/styleguide#core-feature-module.

A reason is the separation of concepts, coreModule must have only modules, providers, components, others that should only be at appModule and not at any other module of your app. This also helps you to make your app module cleaner.

Here you can set HttpClientModule, HTTP_INTERCEPTORS, BrowserAnimationsModule, others.

You can also check out my project where I implemented angular style guide recommendations, such as the core module: here

Answer 2

According to this answer, no. Here is a PR with some more discussion:

@jenniferfell @brandonroberts fyi. @jenniferfell we removed CoreModule as a recommended technique because now the preferred way of providing services is using providedIn, however @bisonfoutu has a great point. I think the focus of this issue might be best suited for a style guide point on Feature Modules or SharedModule section, but I'd love to hear what the team and community have to say.

In the same issue, John Papa explains why you might still want to use it:

This is all great feedback. Now that services can be provided in the root using providedIn it does make it easier to put services where they are needed.

However, the CoreModule was never intended to be a place to put services that should only be defined and used in a sub-ngmodule. So here are my thoughts on this, with some questions to consider.

My domain here is to consider app-wide services. Not ones used only in a sub-ngmodule. What about services used app-wide by needing to be defined in a sub module? Let's hold off on that for a moment.

First - app-wide stuff in the root ...

1. When you have a dozen or so services that are used by the entire app, would you really want to declare them all over the place or in a single place?
2. If the answer to #1 is "yes" then would that place be AppModule? If so, are you comfortable with having a dozen or so of them defined there? Possibly.
3. Would these app wide services be useful in other apps? If so, a Core module can make it easier to test and find these. CoreModule helps here
4. Would these app wide services be good candidates to other apps via an npm library? If so, I might suggest a npm module and not an specific module (via the Angular CLI)

I do think there is some value for a CoreModule for organizational purposes. (see above)

But ... what about a service that a sub module needs and some other one might need. Could you define that in a sub module? Well, you could ... let's walk through that. Assume we have a Customer ngmodule and we define a CustomerService that gets and puts customer data and it uses providedIn to the root. Now another module needs Customer data. You could still use it in that other ngmodule, let's say it handles Orders. So the ngOrders module now uses a service that is provided in the root, but exists in the Customer Module. This works. But is is clear? Is it readable?

New questions based on this new scenario ... How does lazy loading of OrdersModule work now that it depends on a service in the CustomersModule (which is provided in the root)? Is it confusing? What happens if you re-use OrdersModule in another app? It has a dependency that you now need to track down?

IMO - any app-wide "things" should be easily findable. Thus the concept (not the name though) of a CoreModule is still valid and I still use it.

Hope this helps :)

The key takeaways, I think, are that whether or not you use a core module is up to you, but you DO want to make sure you don't include services in a shared module that gets re-imported multiple times, as that will re-instantiate them.