We should mention that providing this way enabled also tree shaking of the service (or lazy loading) if it's only used in lazy-loaded routes/deferred components.

@JeanMeche Would it be accurate to update the intro to say:

When you create a service, you need to provide a configuration object that defines the scope for the service through the providedIn key. This enables Angular to tree-shake the service when it's used in lazy-loaded routes or deferred components.

Trying to think this through how I might frame this...

What do you think of organizing it like:

## How does dependency injection work in Angular?

There are two ways that code interacts with any dependency injection system:
* Code can *provide*, or makes available, values.
* Code can *inject*, or ask for, those values as dependencies.

"Values", in this context, can be any any JavaScript value, including objects and functions.

Angular components and directives automatically participate in DI, meaning that they can inject dependencies _and_ they are available to be injected.

From there, going into "Services" as the most common way of declaring some functionality can can be injected as a dependency, then injecting dependencies, then the full details on providers.

Tokens and injectors IMO can be their own sections later on and don't need to be considered one of the "main concepts", since these are somewhat more intermediate concepts that people don't need to know about right away. I know the outline had a "terminology" section here, but coming back to it now, I think we can drop that.

I would add at least a sentence after the examples about the providedIn: 'root'), even if it's something like

"The `providedIn: 'root'` option controls where this service is available for injection. See [Providing values for injection]() for details.

I think it would be useful to have a subsection here like "Common types of services" and list maybe three to five examples people commonly use services, e.g.

* *Data clients:* abstract the details of making requests to a server for data retrieval and mutation
* *State Management:* defining state shared across multiple components or pages
* *Logging and Error Handling:* making a common API for logging or communicating error states to the user.
* *Event handling and dispatch:* code related to handling events or notifications that are not associated with a specific component, or for dispatching events and notifications to components, following the [observer pattern](https://en.wikipedia.org/wiki/Observer_pattern).

(feel free to tweak these examples, this is just a first pass)

What do you think of, instead of having this "Providers vs Consumers" sections, organizing the topic such that we immediately go into "Injecting dependencies", which would cover the inject function as mechanism by which you retrieve dependencies. i.e., I wouldn't present inject as its own concept, it's just the way you inject things

inject isn't a service, it's just a function.

I think the framing here could be something like

## Injecting dependencies
You can inject dependencies using Angular's `inject` in the constructor of components, directives, pipes, and services.

<example here>

You can only use the `inject` function in an _injection context_.

<something about injection contexts here>

The gist for injection contexts is that it's a part of Angular's lifecycle when you can use the inject function because there's an implicit Injector. We can probably want to just point to a more intermediate/advanced section from here; the the most part, people only need to care that you can call inject in the constructor of components, directives, services, and pipes.