In the next lesson, we'll use something called a service to pass objects between components. This will allow us to pass details about our
Albums, from the general
MarketplaceComponent where they're all listed, to the more-specific
AlbumDetailComponent that will be responsible for displaying information about a single album.
However, to learn about services in Angular we must first have a basic understanding of a design pattern known as dependency injection. This is how services provide data to multiple areas of an application. In this lesson we'll discuss both the language-agnostic dependency injection pattern, and how it specifically relates to Angular services.
Then, in the next lesson we'll walk through the process of creating and injecting a service in our own online marketplace application together. Let's get started!
Dependency injection is a design pattern followed by many frameworks (and softwares), not just Angular.
In a dependency injection design, the dependency is essentially just something helpful. Something we can use to complete a task or small goal. These are often called services. Angular calls them services too.
An injection is the act of providing a dependency or service to an object or area of the application (usually a component, in Angular's case) that needs its help.
You might be surprised by how unexciting that definition is. Why is this so special? Well, usually when part of an application requires something it loads, locates, or constructs it itself. It's the act of passing the service/dependency to the object/component instead of requiring the component to find/build/create the service itself that makes dependency injection different.
In summation: Dependency injection is giving part of an application a helpful thing it needs before it needs it, instead of relying on that part to load, find, or create the helpful thing itself. We just learned a computer science concept!
So, how does Angular use this design pattern? Well, it actually has its own dependency injection system built right in. We'll make use of this pre-existing feature to hand our dependencies (usually services) to the areas of our application (usually components) that require their help.
There are three primary parts of Angular's dependency injection framework: Providers, Services, and Injectors. They all work together to inject dependencies. Let's address what each do in a little more detail:
Services allow us to organize and share the same code and data in many different places throughout our application. Angular has both built-in services, and allows us to create our own custom services.
To help remember what services do, we can think about the word "service" very literally. Any phone book, Yelp page for a city, or other such directory contains many services. There are dog walking services, tree-trimming services, tutoring services, massage services, landscaping services, and more.
Generally, people call these services for assistance when they need help or expertise. For instance, imagine someone is landscaping their new yard, but they don't know what low-maintenance native plants flourish in this area. A local landscaping or gardening service could help them out!
Angular services work the same way: Sometimes our components need information or abilities they simply don't have. When they need help, a service can offer it.
Injectors are like the vehicles that get services where they need to be. The dependency injector is responsible for passing (or "injecting") an instance of the service into the components that need it.
Pretend our friend Jamie studies botany, landscaping, and local plants for years to become a master gardener. This qualifies Jamie to begin providing a service. The service helps other, less-plant-savvy individuals landscape their properties.
Let's pretend Jamie doesn't own a vehicle, and cannot reach their growing client base on public transportation. Another friend Cameron, however, is a professional driver. Cameron drives people around for a living; Uber, Lyft, Taxi cabs, you name it!
So, Cameron and Jamie team up. Cameron zips Jamie around town to meet all clients that require landscaping services. Cameron is the injector in this scenario because Cameron is responsible for getting Jamie's service to all the clients (components!) that need it.
A provider also does what its name suggests: It creates instances of our service, and provides them to the injector. They're like the recipe that knows how to create services.
Providers must be registered with injectors, so injectors know what services they'll be responsible for transporting.
In our fictional example, Jamie is the provider. The expertise, knowledge, and training they offer clients is the service. Whereas Cameron, who transports Jamie (and therefore his service) to the necessary locations is the injector.
To boil it down, the dependency injection process looks something like this:
Don't worry if this feels hazy right now. In the next lesson we'll walk through the actual process of implementing dependency injection into our Angular application. This will all likely make more sense when you begin to see the dependency injection process in action firsthand.