Keep CoreModule as preferred location for app-wide single-use components

📚 Docs or angular.io bug report

Description

The CoreModule guidelines have recently been removed from the style guide. While the CoreModule is indeed not relevant for providing app-wide singleton services now that we have the providedIn option in the @Injectable() decorator, the style guide also gave it another purpose. The CoreModule was the place to go for declaring app-wide single-use components, such as a navigation bar or menu.

I think this recommendation could still be relevant in the style guide.

🔬 Minimal Reproduction

What’s the affected URL?**

https://angular.io/guide/styleguide

Expected vs Actual Behavior**

The CoreModule guidelines have been completely removed from the style guide.

I think that the CoreModule is still a great place to declare app-wide single-use components, along with their dependencies, which would otherwise add some unnecessary cluttering to the AppModule. The SharedModule would not be a good location for these components, since they are not “actually” re-usable. While it is a pretty opinionated choice, I find it useful to have a common place amongst all projects for these specific components, as it used to be the case for app-wide singleton services (I still tend to keep these in a services sub-folder of the core folder, because I find it kind of weird to have a services folder directly under app, alongside feature modules folders).

Feel free to weigh in on this proposal, I’ll be very happy to discuss it further ! 😸

Anything else relevant?

This issue refers to PR #28434 by @kapunahelewong

[johnpapa]

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 😃

[kapunahelewong]

Status: docs team needs to partner with engineering to determine next steps. Great context info above!