Before answering the question, lets figure out what is dependency injection and what are advantages and disadvantages of it.
Dependency injection is a software design pattern that allows to remove hard-coded dependencies and makes it possible to change them. Dependencies can be injected to the object via the constructor or via defined method or a setter property.
Advantages:
- Dependency Injection decreases coupling between an object and its dependency
- Dependency injection doesn't require any change in code behaviour, it can be applied an existing code
- Dependency injection helps isolate the client from the impact of design changes and defects
- Dependency injection allows the system to be reconfigured without changing the existing code
- Dependency injection allows concurrent or independent development
- Dependency injection allows to make code more maintainable and testable, because dependencies’ impact can be removed by replacing dependencies with mocks or stubs
Disadvantages:
- When instantiating type you have to know which dependencies to use
- Hides type’s instantiation and dependency resolving logic and if error happens, it can be much harder to figure out what's wrong
- It can require to write more lines of codes
- It can be slower when instantiating a type with keyword new, it’s related to meta data which has to be used while resolving instance
It’s time to move from theory to practice. Let's take a simple example. In this example we have driver who owns a car and the car can have one engine.
Let’s write some code which implements defined class diagram above.
function Engine() {
this.hp = 256;
}
Engine.prototype.start = function () {
console.log("Engine with " + this.hp + " hp has been started...");
}
function Car() {
this.name = "wv";
this.engine = new Engine();
}
Car.prototype.start = function () {
if (this.engine) {
this.engine.start();
}
}
function Driver() {
this.name = "tom";
this.car = new Car();
}
Driver.prototype.drive = function () {
if (this.car) {
this.car.start();
}
}
var driver = Driver();
driver.drive();
// Engine with 256 hp has been started...
From the first view everything looks OK. This code works. If you don’t need to test it or to change it in the future, this is code is fine. However, this code has some issues, one of which is that dependencies are hard-coded.
function Engine(hp) {
this.hp = hp;
}
Engine.prototype.start = function () {
console.log("Engine with " + this.hp + " hp has been started...");
}
function Car(name, engine) {
this.name = name;
this.engine = engine;
}
Car.prototype.start = function () {
if (this.engine) {
this.engine.start();
}
}
function Driver(name, car) {
this.name = name;
this.car = car;
}
Driver.prototype.drive = function () {
if (this.car) {
this.car.start();
}
}
var driver = Driver("tom");
driver.car = new Car("wv", new Engine(256)));
driver.drive();
// Engine with 256 hp has been started...
We have modified our existing code and it is extensible, but driver’s creation procedure has become more complex. In this case dependency injection container can help us. You can define driver’s details in configuration and when you want to instantiate driver you have to do it using dependency injection resolver. In the example below di4js library is used.
di
.register('engine')
.as(Engine)
.withConstructor()
.param().val(256)
.register('car')
.as(Car)
.withConstructor()
.param().val('wv')
.param().ref('engine')
.register('driver')
.as(Driver)
.withConstructor()
.param().val('tom')
.param().ref('car');
var driver = di.resolve('driver');
driver.drive(); // Engine with 256 hp has been started…
As I mentioned before, that dependency injection may required to write more code as we can see in this example, on the other hand, there is one advantage that configuration is defined in a single place and it can reconfigured without changing the existing code base.
Autowire
If you do not want to define all dependencies manually, there is a solution. You can enable autowired option. If it is enabled for dependency resolver, all type's or instance's dependencies are resolved automatically by names. It may reduce the amount of code necessary to register types and their dependencies. With autowired option enabled you have to register only types. By default autowired is disabled.
Let’s simplify the example in order to show how autowired option works.
function Engine() {
}
Engine.prototype.start = function () {
console.log("Engine has been started...");
}
function Car() {
this.engine = null;
}
Car.prototype.start = function () {
if (this.engine) {
this.engine.start();
}
console.log("Car has been started...");
}
di
.autowired(true)
.register('engine')
.as(Engine)
.register('car')
.as(Car);
var car = di.resolve('car');
car.start();
We are going to see such output in console.
"Engine has been started..." "Car has been started..."
One more and the most common scenario is mixed mode. By default you can allow to resolve dependencies automatically but some dependencies can be defined manually. Manually defined dependency has bigger priority.
If you are using different naming convention from the one given in the example it can be overridden easily. For more details read di4js documentation.
List of Dependencies
In some situations you may need to resolve a list of dependencies. To achieve this you have to make multiple registrations for single name.
Let’s modify our previous example and let’s say that driver can own more than one car at the same time which one to drive. Modified class diagram can be found below.
First of all we need to modify driver’s definition. Property ‘car’ has to be renamed to ‘cars’ and additional parameter ‘name’ has to be added to method ‘drive’. Let’s look to our modified source code.
function Driver(name) {
this.name = name;
}
Driver.prototype.drive = function (name) {
if (this.cars && name) {
if (this.cars instanceof Array) {
for (var i = 0; i < this.cars.length; i++) {
if (this.cars[i].name === name) {
this.cars[i].start();
break;
}
}
} else if (this.cars.name === name) {
this.cars.start();
}
}
}
It’s time to register driver’s dependencies and try to resolve it.
di
.register('engine')
.as(Engine)
.withConstructor()
.param().val(256)
.register('car')
.as(Car)
.withConstructor()
.param().val('wv')
.param().ref('engine')
.register('car')
.as(Car)
.withConstructor()
.param().val('ford')
.param().ref('engine')
.register('tom')
.as(Driver)
.withConstructor()
.param().val('tom')
.withProperties()
.prop("cars").ref('car');
To instantiate driver by name we need to write a single code line.
var tom = di.resolve('tom');
If we invoke method ‘drive’, we will get results which will be printed to console output.
tom.drive('wv');
// Engine with 256 hp has been started…
// Car 'wv' has been started...
Using setter methods instead of properties / fluent interface
There is one more fancy feature. Some objects do not have properties, they have only setter methods and fluent interface. Such scenario with di4js library can be handled too. There is one limitation that these dependencies can not be resolved automatically.
Let’s modify our previous example and replace properties with setter methods.
New defined methods look like this.
Car.prototype.setEngine = function (engine) {
this.engine = engine;
return this;
};
Driver.prototype.setCars = function (cars) {
this.cars = cars;
return this;
};
Below you can see how modified type and its dependencies registration look.
di
.register('engine')
.as(Engine)
.withConstructor()
.param().val(256)
.register('car')
.as(Car)
.withConstructor()
.param().val('wv')
.withProperties()
.func('setEngine')
.param().ref('engine')
.register('car')
.as(Car)
.withConstructor()
.param().val('ford')
.withProperties()
.func('setEngine')
.param().ref('engine')
.register('tom')
.as(Driver)
.withConstructor()
.param().val('tom')
.withProperties()
.func('setCars')
.param().ref('car');
If we resolve driver and invoke its method ‘drive’, we will get the same result as in previous examples.
Child container
In all examples global dependency resolver is used, it’s good for demo purposes and small apps. For bigger apps child dependency resolvers should be created per scope. It allows to get better flexibility and extensibility. Parent can be extended or overridden by child without making an impact on it.
First of all let’s register type in global dependency resolver and then try to resolve registered type by name.
var DieselEngine = function () {
};
DieselEngine.prototype.start = function () {
console.log("Diesel engine has been started...");
};
function Car(engine) {
this.engine = engine;
}
Car.prototype.start = function () {
if (this.engine) {
this.engine.start();
}
console.log("Car has been started...");
}
di
.autowired(true)
.register('engine')
.as(DieselEngine)
.register('car')
.as(Car);
var car = di.resolve('car');
car.start();
We are getting such results.
"Diesel engine has been started..." "Car has been started..."
Now we can create a child container from the parent and then try to resolve overridden type.
var PetrolEngine = function () {
};
PetrolEngine.prototype.start = function () {
console.log("Petrol engine has been started...");
};
var child = di
.create()
.register('engine')
.as(PetrolEngine);
car = child.resolve('car');
car.start();
Now we are getting different results.
"Petrol engine has been started..." "Car has been started..."
Injection to function or object
There is a situation when instance creation can’t be controlled by dependency injection resolver. This situation may occur when you are adapting dependency injection for legacy code or instances are created by other components which you do not control. There is an option to inject dependencies to object or to function.
The first example demonstrates how dependencies can be injected to the function using parameters’ names.
di.inject(function (car) {
car.start();
});
In the second example an array notation is used to inject dependencies to the function.
di.inject(['car', function (car) {
car.start();
}]);
In the following examples I have demonstrated how to inject dependencies to the function. In following examples I am going to demonstrate how dependencies can be injected to an object.
var car = new Car(); di.inject(car); car.start();
There is the second method how to inject dependencies to object. You have to provide registration name which has to be used while injecting dependencies.
var car = new Car(); di.inject(car, 'car'); car.start();
AMD
di4js is compatible with asynchronous module definition (AMD) and it can be loaded as ordinal module.
define(['di4js'], function (di) {
function Engine(hp) {
this.hp = hp;
}
Engine.prototype.start = function () {
console.log("Engine with " + this.hp + " hp has been started...");
}
di
.register("engine")
.as(Engine)
.withConstructor()
.param().val(256);
var engine = di.resolve("engine");
engine.start();
});
Testing
As I mentioned before, if you are using dependency injection your code is maintainable and testable, because dependencies can be replaced with stubs or mocks easily.
In the following example I am going to use a well known testing framework Jasmine. I am going to demonstrate how we can test single method replacing dependencies with mocks.
describe("car", function() {
it("should start a car", function() {
var engineMock = jasmine.createSpyObj('engine', ['start']);
var car = new Car(engineMock);
car.start();
expect(engineMock.start).toHaveBeenCalled();
});
});
As we can see in the example such code can be tested easily.
Why di4js?
di4js is lightweight library which is inspired by Unity, Spring, AngularJS and others. di4js advantages are that it is a small library and it’s dedicated to solve a certain problem, thus it’s not a massive framework which tries to cover everything. It also doesn’t depend on other libraries, so it’s easy to embed it to an existing code base.
You may ask why it was created. The answer is simple. A range of libraries have been investigated and none of them satisfied expectations. The goal was to gather various components from various libraries to a single place. Initially it was written for internal purpose but now a decision has been made to share it. Maybe it will be useful for others too.
di4js can be used in projects which are not build on big frameworks such as AngularJS, because big frameworks have built in solution for dependency management. di4js can be useful when you depend on small dedicated libraries.
Usage
di4js library is released under MIT license. It can be used in modern browsers or in other JavaScript runtimes such as Node.js. Library can be installed from various package managers: nuget, npm or Bower.
To install di4js module for Node.js, this command should be used:
npm install di4js
To install di4js for web browser, run the following command:
bower install di4js
In Visual Studio di4js module can be installed using NuGet extension. To install di4js, run the following command in the package manager console.
Install-Package di4js
If you want to look at the source code or to get more information about library or its usage, just vist https://github.com/gedbac/di4js.
Final thoughts
At the beginning we asked a question “Can dependency injection pattern be used in JavaScript?”. Now we can answer to that question and say that dependency injection can be easily used and is useful in JavaScript, but project size and complexity always has to be considered. Thus, problem has to be identified and after that corresponding solution has to be chosen. Consequently, we can say that every pattern which is used in other languages can be easily adapted to the JavaScript.
