ioc-service-container

ioc-service-container

This is a lightweight library for a service container written in TypeScript.

Get started

Install the dependency with npm install ioc-service-container

Usage

First set up an Enum for preventing typos or redefinition of service ids:

export enum ServiceId {
  TestApi = 'TestApi',
  TestService = 'TestService',
  FooApi = 'FooApi',
}

According to this you have to pass a factory of your required services to the ioc container. So at the initial script of your application you call a function named e.g. setupServiced:

function setupServiced() {
  ServiceContainer.set(ServiceId.TestApi, () => new CustomTestApi());
  ServiceContainer.set(ServiceId.FooApi, () => new CustomFooApi());
  ServiceContainer.set(ServiceId.TestService, () => new CustomTestService());
}

Now you have two options to inject the requested service. The first one is without the usage of TypeScript annotations. This can be used anywhere in your code:

const testService = ServiceContainer.get<TestService>(ServiceId.TestApi);
const testApi = ServiceContainer.get<TestService>(ServiceId.TestService);

The second option is to use the @inject decorator inside a class:

export class CustomTestService implements TestService {
  @inject
  private readonly customApi!: Api; // Important is the naming of the property, its mapped to the serice id

  @inject(ServiceId.FooApi) // If you don't want to name your property like the service id, use this decorator
  private readonly nameThisHowYouWant!: Api;

  private readonly barApi = ServiceContainer.get<Api>(ServiceId.BarApi) // Use this syntax if you don't want to use decorators
}

Your can see a demo in the ./example folder. To run this type in npm run example.

Background

Structuring your code and avoiding implizit dependencies is two of the most effective ways to avoiding bugs, especially when code gets extended. To goal of Dependency Injection (DI) is to prevent structures like this:

class CustomService {
  constructor() {
    this.api = new CustomApi();
  }
}

The CustomService has an implizit dependency to the CustomApi.

Goal

The goal of DI is to encapsulate the dependencies of a class. The CustomService should work without knowing which api it is using. Following structure should be created:

+----------+    +-------------------+
|          |    |                   |
| Consumer +--->+ interface Service |
|          |    |                   |
+----------+    +---------+---------+
                          ^
                          |
                          |
                +---------+-----------+     +----------------+
                |                     |     |                |
                | class CustomService +---->+  interface Api |
                | implements Service  |     |                |
                |                     |     +--------+-------+
                +---------------------+              ^
                                                     |
                                                     |
                                            +--------+--------+
                                            |                 |
                                            | class CustomApi |
                                            | implements Api  |
                                            |                 |
                                            +-----------------+

(Btw asciiflow.com is a great tool for creating small charts for e.g. Readme.md)