add tree-shakable providers doc

[sreevani-ship-it]

PR Checklist

Please check if your PR fulfills the following requirements:

• The commit message follows our guidelines: https://github.com/angular/angular/blob/master/CONTRIBUTING.md#commit
• Tests for the changes have been added (for bug fixes / features)
• Docs have been added / updated (for bug fixes / features)

PR Type

What kind of change does this PR introduce?

[ ] Bugfix
[ ] Feature
[ ] Code style update (formatting, local variables)
[ ] Refactoring (no functional changes, no api changes)
[ ] Build related changes
[ ] CI related changes
[x] Documentation content changes
[ ] angular.io application / infrastructure changes
[ ] Other... Please describe:

What is the current behavior?

Other information

#22803 - Orginal PR

[mary-poppins]

You can preview 2c58b45 at https://pr23027-2c58b45.ngbuilds.io/.

[mary-poppins]

You can preview 87643c1 at https://pr23027-87643c1.ngbuilds.io/.

[about-code]

Current drafts on treeshakable providers in https://pr22803-95a505f.ngbuilds.io/guide/dependency-injection#creating-tree-shakable-providers suggest that a replacement of an injectable type should/could be declared in the same module which defines the injectable type, e.g.

@Injectable({ 
  providedIn: 'root', 
  useClass: FooServiceImpl  // same with useFactory
}) 
export class FooService {}

What I've learnt about DI, though, is that DI is meant to decouple a service consumer (which depends on an interface type like FooService) from a concrete implementation like FooServiceImpl in order to be able to inject alternative implementations or mocks of the interface type into the consumer without having to alter service consumer nor service interface type (because I may neither be consumer nor interface type provider but a third-party providing an alternative implementation)

But if I do specify an implementation of an interface in the same module which declares the interface type then this does seem to me like a tight coupling of an interface type and a concrete implementation. What's the point of DI then, anymore? The drafts look like that by choosing and injecting the interface type one does also inevitably choose a concrete implementation. Then I could do new FooServiceImpl() in the service consumer, once again like I did in the "good" old days without DI.

Or should FooServiceImpl be considered more kind of a default implementation which could be overriden with an alternative implementation provided via some AppModule provider? But if this syntax is about default implementations is it required at all? I mean FooService could be that default implementation itself, then.

What am I missing? I do understand tree shaking and I actually do understand dependency injection but it seems to me like the concepts are fundamentally incompatible if something like the above is the only way to make it somehow work together. Would love to find out where I miss the point.

[mary-poppins]

You can preview e92c137 at https://pr23027-e92c137.ngbuilds.io/.

[jenniferfell]

@alxhub Can you provide some insight on the question from @about-code ? Thanks!

[alxhub]

@about-code you're not missing anything, you actually answered your own question.

Or should FooServiceImpl be considered more kind of a default implementation which could be overriden with an alternative implementation provided via some AppModule provider?

Yes, exactly.

But if this syntax is about default implementations is it required at all? I mean FooService could be that default implementation itself, then.

Yes, it could:

@Injectable({providedIn: 'root'})
export class FooService {
  ...
}

Every token must have a provider in order to be injected. @NgModule allowed you to define that provider in 4 ways: class, existing, factory, and value. @Injectable has the same level of flexibility, but moving the definition onto the type itself (as a sort of "default provider" as you called it) allows the type to be removed if it's not referenced.

[jenniferfell]

@alxhub : @chembu has incorporated the code snippets from your example. Time for approval review, meaning:

1. Make sure all changes you requested previously are incorporated
2. Check that any reviewer comments on this thread have been incorporated into doc to your satisfaction
3. Check for any show-stoppers.
4. Indicate your approval so pull-approve passes.

I'm doing the same as co-approver from doc team.

Please review by EOD 3/30. We need to have any final critical changes incorporated by @chembu , your approval, and mark for merge by EOD 4/2. Thanks! (target is next RC)

[jenniferfell]

@IgorMinar Can you also provide an approval. We need an approval from you or someone else in the guide-and-tutorial group. This PR doesn't touch tutorial files, just ngmodule and DI files, but pull-approve is asking for the guide-and-tutorial group. Thanks!

[jenniferfell]

There are some code snippets directly embedded here. Will those be coming from a live example soon?

Lots of notes, but I don't think there are any show stoppers. Some suggestions for clarifying sections that were hard to parse. Some replacements of which with that for accuracy. A few typos. If they don't make it in for this merge, please capture externally somehow for the next rev.

[jenniferfell]

Edit: Feels like a word is missing. "Do provide a service with the app root injector..."

[jenniferfell]

Edit: Who provides the service to a root injector? The way this is phrased "that instance of the service" is what provides the service to a root injector. I think the intent is "When you provide the service to a root injector..." ?

[jenniferfell]

Edit: I would break this into two "why" statement. The first is about scope. The second is about tree-shaking. I would also pull the 3rd why ("This is ideal when a service is sharing methods or state.") up to be part of the first half of this. "When you provide the service to a root injector, that instance of the service is .... This is ideal when.... "

[sreevani-ship-it]

Done

[jenniferfell]

Edit: This is hard to parse. Does "which" refer to the services and providers? Or to modules? It also seems like the clause is restrictive, so "that" instead of "which".

"...configure services and providers that are intended to be singletons"?
"...configure services and providers for modules that are intended to be singletons"

[sreevani-ship-it]

Done

[jenniferfell]

Edit: Instead of "it is preferable", I recommend: "For a service, instead of using forRoot(), specify providedIn: 'root' on the service's @Injectable() decorator. This has the same effect, and is preferred." Because....can we say why?

[sreevani-ship-it]

Explained why to use @Injectable() decorator

[jenniferfell]

Edit: Rearrange so there isn't a heading followed by "For example." This structure breaks up the context of what is being demonstrated. It also is confusing for someone who uses the right nav to jump to this section.

[jenniferfell]

Typo: Missing s in "one of these component instances"

[jenniferfell]

Edit: Because of

[jenniferfell]

Edit: I'm not sure of the right answer technically, but the paragraph above doesn't parse well and has grammar issues. One attempt:

You can directly configure a provider when creating an InjectionToken. Directly configuring a provider determines which injector provides the token and how the value is created. Using an InjectionToken is similar to using @Injectable, expect that you cannot define standard providers such as useClass or useFactory. Instead, you specify a factory function that returns the value to be provided directly.

[sreevani-ship-it]

Re-phrased.

[jenniferfell]

Examples: Will these code snippets be coming from live examples?

[about-code]

@alxhub Thank you for your clarification.

[alxhub]

LGTM, commented a couple of times for technical clarity.

[mary-poppins]

You can preview 26fe94d at https://pr23027-26fe94d.ngbuilds.io/.

[mary-poppins]

You can preview 63e7dde at https://pr23027-63e7dde.ngbuilds.io/.

[jenniferfell]

@IgorMinar Can you also provide an approval. We need an approval from you or someone else in the guide-and-tutorial group. This PR doesn't touch tutorial files, just ngmodule and DI files, but pull-approve is asking for the guide-and-tutorial group. AlexR has approved. Thanks!

[IgorMinar]

lgtm

[angular-automatic-lock-bot]

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

_{This action has been performed automatically by a bot.}