This post was originally published on Sep 17, 2015 but has been updated to reflect the latest information.
If you’re following our articles on Dependency Injection in Angular 2, you know how the DI system in Angular works. It takes advantage of metadata on our code, added through annotations, to get all the information it needs so it can resolve dependencies for us.
This article discusses what this unexpected problem is, why it exists and how it can be solved.
Injecting Service Dependencies
Let’s say we have a simple Angular 2 component which has a
DataService dependency. It could look something like this:
DataService on the other hand is a simple class (because that’s what a service in Angular 2 is), that provides a method to return some items.
Of course, in order to actually be able to ask for something of type
DataService, we have to add a provider for our injector. We can do that by adding a provider to our component.
Until now there’s nothing new here. If this is new to you, you might want to read our article on Dependency Injection in Angular 2 first.
So where is the problem? Well, the problem occurs as soon as we try to inject a dependency into our service. We could for example use
Http in our
DataService to fetch our data from a remote server. Let’s quickly do that. First, we need to import Angular’s
HttpModule into our application module.
Angular’s http module comes with all the providers we need to hook up some http action in our service. Next, we need to inject an instance of
Http in our service to actually use it.
Boom. This thing is going to explode. As soon as we run this code in the browser, we’ll get the following error:
Cannot resolve all parameters for DataService(?). Make sure they all have valid type or annotations.
It basically says that it can’t resolve the
Http dependency of
DataService because Angular doesn’t know the type and therefore, no provider that can be used to resolve the dependency. Uhm.. wait what? Didn’t we put the type in the constructor?
Yea, we did. Unfortunately it turns out this is not enough. However, obviously it does work when we inject
DataService in our
AppComponent. So what’s the problem here? Let’s take a step back and recap real quick where the metadata, that Angular’s DI need, comes from.
In our article on the difference between decorators and annotations we learned that decorators simply add metadata to our code. If we take our
AppComponent, once decorated and transpiled, it looks something like this (simplified):
We can clearly see that
AppComponent is decorated with
Component, and some additional metadata for
paramtypes metadata is the one that is needed by Angular’s DI to figure out, for what type it has to return an instance.
This looks good. Let’s take a look at the transpiled
DataService and see what’s going on there (also simplified).
Oops. Apparently we don’t have any metadata at all here. Why is that?
TypeScript generates metadata when the
emitDecoratorMetadata option is set. However, that doesn’t mean that it generates metadata blindly for each and every class or method of our code. TypeScript only generates metadata for a class, method, property or method/constructor parameter when a decorator is actually attached to that particular code. Otherwise, a huge amount of unused metadata code would be generated, which not only affects file size, but it’d also have an impact on our application runtime.
That’s also why the metadata is generated for
AppComponent, but not for
AppComponent does have decorators, otherwhise it’s not a component.
Enforcing Metadata Generation
So how can we enforce TypeScript to emit metadata for us accordingly? One thing we could do, is to use DI decorators provided by the framework. As we learned in our other articles on DI, the
@Inject decorator is used to ask for a dependency of a certain type.
We could change our
DataService to something like this:
Problem solved. In fact, this is exactly what
@Inject is for when not transpiling with TypeScript. If we take a look at the transpiled code now, we see that all the needed metadata is generated (yeap simplified).
However, now we have this Angular machinery in our code and unfortunately, we won’t entirely get rid of it. We can do a little bit better though. Remember that we said metadata is generated, if decorators are attached to our code?
We can basically put any decorator on our code, as long as it’s either attached to the class declaration, or to the constructor parameter. In other words, we could remove
@Inject again and use something else that we put on the class, because that will cause TypeScript to emit metadata for the constructor parameters too.
Of course, putting just anything that is a decorator on a class doesn’t sound really appropiate. Luckily, Angular comes with yet another decorator we can use.
@Injectable is normally used for Dart metadata generation. It doesn’t have any special meaning in TypeScript-land, however, it turns out to be a perfect fit for our use case. We don’t have to build a new one ourselves, and the name also kind of makes sense.
All we have to do is to import it and put it on our
DataService like this:
Again, this will just enforce TypeScript to emit the needed metadata, the decorator itself doesn’t have any special meaning here. This seems to be currently the best option we have to solve the illustrated problem.
Get updates on new articles and trainings.
Join over 1000 other developers who get our content first.
Custom Form Controls in Angular 2
Angular makes it very easy to create custom form controls. Read on to learn how to do it!
Protecting Routes using Guards in Angular 2
Angular's router enables protecting routes using guards and in this article we're going to discuss how to implement them.
Reactive Forms in Angular 2
Angular allows us to build forms in a model-driven fashion. In this article we're going to discuss what that looks...
Cold vs Hot Observables
In this article we are going to demystify what the term hot vs cold means when it comes to Observables....
Routing in Angular 2 revisited
Learn how to implement basic routing in your Angular 2 application using the latest and greatest APIs!
Component-Relative Paths in Angular 2
Component-relative enable developers to more easily create maintainable, reusable, portable components in Angular 2. Here's how!