Splitting related functionality into its own Angular component results in improved organization and maintenance. However, the structure of Angular components are focused on delivering a visual representation on screen. Sometimes we want to organize a set of related code into a logical unit that has no direct on-screen representation, and that is why the tutorial teaches us how to create Angular services.

Since there is nothing on screen, Angular services are a little more abstract and involve moving parts we haven't seen yet. I re-read "Provide the HeroService" section several times and I still don't feel like I have a good grasp of "service", "provider", and "injector". I don't see why "service" and "provider" are two different concepts, as the tutorial provider instantiates the service class. Perhaps a service can be provided by one of several different providers? Or perhaps a service class can be created by multiple providers? Or is there a 1:1 relationship but they need to be kept separate for some reason I don't understand? That is an exercise left for later. As for injectors, we use a single global injector in the tutorial. Having multiple injectors -- and when it would make sense to do so -- is outside the scope of this tutorial.

It didn't help that the section started with one bear of a compound sentence:

You must make the HeroService available to the dependency injection system before Angular can inject it into the HeroesComponent by registering a provider.

There are multiple ways to parse this sentence. My initial reading was "You must (make the HeroService available to the dependency injection system) before (Angular can inject it into the HeroesComponent by registering a provider.)" but now I think it is "You must (make the HeroService available to the dependency injection system) before (Angular can inject it into the HeroesComponent) by (registering a provider)." But either way I think this sentence should be broken up and rewritten. If I grow in my Angular knowledge to understand what's going on (which I don't at the moment) I can try my hand at rewriting that sentence and submit a pull request.

Once we created the service class, we progressed to the implementation which showcased how asynchronous operations are handled in Angular applications. The concept is called "Observable Data" and it is subcontracted out to a separate project named RxJS. I read over the RxJS Overview page and it was clear I did not meet the prerequisites for this class. Reading things like "Think of RxJS as Lodash for events." didn't help me at all given my ignorance of JavaScript events and whatever Lodash is. But the examples that followed looked mildly interesting. I guess if I had more experience with JavaScript event handler oddities, I would find RxJS more compelling. But for now it's just another pattern I'll learn to use without really understanding why it came to be that way.

Which is a fair description of this services section of the Angular tutorial, actually. The Heroes service is followed by another service example to represent Message. And given the overlap, Message service included fewer explanations than earlier. I think I'm still mostly keeping up, but there's definitely less comprehension and understanding as I copy and paste. Thankfully I had an easier time following the next section on in-app navigation.