true-di v3.0.0

true-di

true-di is a Simple Dependency Injection Container for TypeScript and JavaScript

Installation

npm i --S true-di

yarn add true-di

Documentation

Read Documentation on Git Book

Usage Example:

./src/container.ts

import diContainer from 'true-di';
import { IContainer } from './interfaces';
import Logger from './Logger';
import DataSourceService from './DataSourceService';
import ECommerceService from './ECommerceService';


const container = diContainer<IContainer>({
  logger: () =>
    new Logger(),

  dataSourceService: ({ logger }) => 
    new DataSourceService(logger),

  ecommerceService: ({ logger, dataSourceService }) =>
    new ECommerceService(logger, dataSourceService),
});

export default container;

./src/controller.ts

import Express from 'express';

export const getOrders = async (req: Express.Request, res: Express.Response) => {
  const { ecommerceService } = req.container;
  res.json(
    await ecommerceService.getOrders()
  );
}

./src/index.ts

import express from 'express';
import container from './container';
import { getOrders } from './controller';

const app = express();

app.use((req, res, next) => {
  req.container = container;
  next();
});

app.get('/orders', getOrders);
app.listen(8080);

Live Demo on Sandbox

Why true-di?

1. It's light and idiomatic.
2. It works with JavaScript and TypeScript.
3. It's well-typed. Items types are always known whenever your code assess them.
4. It is Isomorphic: works on Back end and on Front end.
5. It works with Classes and with Closures.
6. It doesn't require decorators (annotations).
7. It doesn't depend on reflect-metadata.
8. It allows referring items without strings or other artificial elements.
9. It uses getters under the hood.
10. It's lazy: container doesn't create an item until your code requests
11. It automatically resolves dependencies
12. It immediately falls down on constructor-injection of cyclic dependency
13. It supports property-, setter- cyclic dependencies
14. It doesn't know anything about context but it could be easily placed into the context.
15. Its containers are composable.
16. It's SOLID-compatible.
17. It's more SOLID-compatible then other IOC solutions. Your code doesn't need to depend on the container (nor even on its interface).
18. It's testable.
19. It supports symbolic names.
20. It doesn't have any other dependencies (and it will be kept)