Understanding Dependency Injection in TypeScript

0
337
views

One thing I really like about mature frameworks is that they all implement some kind of dependency injection. Recently I’ve played around with this technology in TypeScript to get a better understanding of how it works beneath the surface.

What is dependency injection (DI)?

In case you have no idea what DI is, I highly recommend to get in touch with it. Since this post should not be about the What? but more about the How? let’s try to keep this as simple possible at this point:

Dependency injection is a technique whereby one object supplies the dependencies of another object.

Quote from Wiki

What does that mean? Instead of manually constructing your objects some piece (often called Injector) of your software is responsible for constructing objects.

Imagine the following code:

class Foo {
}

class Bar {
  constructor(foo: Foo) {
  }
}

class Foobar {
  constructor(foo: Foo, bar: Bar) {
  }
}

To get an instance of Foobar you’d need to construct it the following way:

const foobar = new Foobar(new Foo(), new Bar(new Foo()));

Not cool.

By using an Injector, which is responsible for creating objects, you can simply do something like:

const foobar = Injector.resolve<Foobar>(Foobar); // returns an instance of Foobar, with all injected dependencies

Better.

There are numerous resons about why you should dependency injection, including testability, maintainability, readability, etc.. Again, if you don’t know about it yet, it’s past time to learn something essential.

Dependency injection in TypeScript

This post will be about the implementation of our very own (and very basic) Injector. In case you’re just looking for some existing solution to get DI in your project you should take a look at InversifyJS, a pretty neat IoC container for TypeScript.

What we’re going to do in this post is we’ll implement our very own Injector class, which is able to resolve instances by injecting all necessary dependencies. For this we’ll implement a @Service decorator (you might know this as @Injectable if you’re used to Angular) which defines our services and the actual Injector which will resolve instances.

Before diving right into the implementation there might be some things you should know about TypeScript and DI:

Reflection and decorators

We’re going to use the reflect-metadata package to get reflection capabilities at runtime. With this package it’s possible to get information about how a class is implemented – an example:

const Service = () : ClassDecorator => {
  return target => {
    console.log(Reflect.getMetadata('design:paramtypes', target));
  };
};

class Bar {}

@Service()
class Foo {
  constructor(bar: Bar, baz: string) {}
}

This would log:

[ [Function: Bar], [Function: String] ]

Hence we do know about the required dependencies to inject. In case you’re confused why Bar is a Function here: I’m going to cover this in the next section.

Important: it’s important to note that classes without decorators do not have any metadata. This seems like a design choice of reflect-metadata, though I’m not certain about the reasoning behind it.

The type of target

One thing I was pretty confused about at first was the type of target of my Service decorator. Function seemed odd, since it’s obviously an object instead of a function. But that’s because of how JavaScript works; classes are just special functions:

class Foo {
    constructor() {
        // the constructor
    }
    bar() {
        // a method
    }
}

Becomes

var Foo = /** @class */ (function () {
    function Foo() {
        // the constructor
    }
    Foo.prototype.bar = function () {
        // a method
    };
    return Foo;
}());

After compilation.

But Function is nothing we’d want to use for a type, since it’s way to generic. Since we’re not dealing with an actual instance at this point we need a type which describes what type we get after invoking our target with new:

interface Type<T> {
  new(...args: any[]): T;
}

Type<T> is able to tell us what an object is instances of – or in other words: what are we getting when we call it with new. Looking back at our @Service decorator the actual type would be:

const Service = () : ClassDecorator => {
  return target => {
    // `target` in this case is `Type<Foo>`, not `Foo`
  };
};

One thing which bothered me here was ClassDecorator, which looks like this:

declare type ClassDecorator = <TFunction extends Function>(target: TFunction) => TFunction | void;

That’s unfortunate, since we now do know the type of our object. To get a more flexible and generic type for class decorators:

export type GenericClassDecorator<T> = (target: T) => void;

Interfaces are gone after compilation

Since interfaces are not part of JavaScript they simply disappear after your TypeScript is compiled. Nothing new, but that means we can’t use interfaces for dependency injection. An example:

interface LoggerInterface {
  write(message: string);
}

class Server {
  constructor(logger: LoggerInterface) {
    this.logger.write('Service called');
  }
}

There’ll be no way for our Injector to know what to inject here, since the interface is gone at runtime.

That’s actually a pity, because it means we always have to type-hint our real classes instead of interfaces. Especially when it comes to testing this may be become really unforunate.

There are workarounds, e.g. using classes instead of interfaces (which feels pretty weird and takes away the meaningfulness of interfaces) or something like

interface LoggerInterface {
  kind: 'logger';
}

class FileLogger implements LoggerInterface {
  kind: 'logger';
}

But I really don’t like this approach, since its redundant and pretty ugly.

Circular dependencies causes trouble

In case you’re trying to do something like:

@Service()
class Bar {
  constructor(foo: Foo) {}
}

@Service()
class Foo {
  constructor(bar: Bar) {}
}

You’ll get a ReferenceError, telling you:

ReferenceError: Foo is not defined 

The reason for this is quite obvious: Foo doesn’t exist at the time TypeScript tries to get information on Bar.

I don’t want to go into detail here, but one possible workaround would be implementing something like Angulars forwardRef.

Implementing our very own Injector

Okay, enough theory. Let’s implement a very basic Injector class.

We’re going to use all the things we’ve learned from above, starting with our @Service decorator.

The @Service decorator

Our @Service decorator has only one purpose: pass all classes to our Injector, which stores them. Hence it’s a pretty simple and small decorator:

// ServiceDecorator.ts

const Service = () : GenericClassDecorator<Type<any>> => {
  return (target: Type<any>) => {
    Injector.set(target);
  };
};

The Injector

The injector acts as a store for all services and is able to resolve requested instances. First let’s implement storing capabilities:

// Injector.ts

export const Injector = new class {
  // A map where all registered services will be stored
  protected services: Map<string, Type<any>> = new Map<string, Type<any>>;
  
  // store services within the injector
  set(target: Type<any>) {
    this.services.set(target.name, target);
  }
};

The reason for exporting a constant instead of a class (like export class Injector [...]) is that our Injector is a singleton. Otherwise we’d never get the same instance of our Injector, meaning everytime you import the Injector you’ll get an instance of it which has no services registered. (Like every singleton this has some downsides, especially when it comes to testing. Implementing a method to clear stored instances and called before tests might be useful here.)

Services will be stored in a Map<string, Type<any>>, where the key is just the name of our class.

Note: I try to avoid any as much as possible, but literally any class can be a service. If your services implement an interface like ServiceInterface, slightly change the type of targets to Type<ServiceInterface>.

The next thing we need to implement is a method for resolving our instances:

// Injector.ts

export const Injector = new class {
  // A map where all registered services will be stored
  protected services: Map<string, Type<any>> = new Map<string, Type<any>>();
  
  // resolving instances
  resolve<T>(target: Type<any>): T {
    // tokens are required dependencies, while injections are resolved tokens from the Injector
    let tokens = Reflect.getMetadata('design:paramtypes', target) || [],
        injections = tokens.map(token => Injector.resolve<any>(token));
    
    return new target(...injections);
  }
  
  // store services within the injector
  set(target: Type<any>) {
    this.services.set(target.name, target);
  }
};

That’s it. Our Injector is now able to resolve requested instances. Let’s get back to our (now slightly extended) example at the beginning and resolve it via the Injector:

@Service()
class Foo {
  doFooStuff() {
    console.log('foo');
  }
}

@Service()
class Bar {
  constructor(public foo: Foo) {
  }

  doBarStuff() {
    console.log('bar');
  }
}

@Service()
class Foobar {
  constructor(public foo: Foo, public bar: Bar) {
  }
}

const foobar = Injector.resolve<Foobar>(Foobar);
foobar.bar.doBarStuff();
foobar.foo.doFooStuff();
foobar.bar.foo.doFooStuff();

Console output:

bar
foo
foo

Meaning that our Injector successfully injected all dependencies. Wohoo!

Conclusion

Dependency injection is a powerful tool you should definitely utilise. This post is about how DI works and should give you a glimpse of how to implement your very own injector.

There are still many things to do. To name a few things:

  • error handling
  • handle circular dependencies
  • store resolved instances
  • ability to inject more than constructor tokens
  • etc.

But basically this is how an injector could work.

As said at the beginning I’ve just recently begun with digging in DI implementations. If there’s anything bothering you about this article or how the injector is implemented feel free to tell me in the comments.

And, as always, the entire code (including examples and tests) can be found on GitHub.

Source: https://nehalist.io/dependency-injection-in-typescript/

LEAVE A REPLY

Please enter your comment!
Please enter your name here