DEV Community

Dependency Injection in JavaScript

K on October 23, 2017

Cover image by PapiertrÃ¼mmer on Flickr Why? We all write code that depends on other code, this is completely normal. Even if we don't ...

Read full post

Bart Karalus • Oct 23 '17 • Edited

To put my two penny worth into this, I think one underrated benefit from this approach is that the code becomes more testable out of the box. If you think about component mocking, it is suddenly super easy to mock an object and inject it like nothing happened. :) But that is in general, not only JavaScript related.

Jilles van Gurp • Oct 23 '17

This is in fact the reason a lot of Javascript code is notoriously hard to test. You basically need a complete browser to test even the most trivial stuff. Testability and good design go hand in hand. Anything that can be injected, can trivially be mocked. Once everything not core to the unit you are testing is injectable, the thing is highly testable.

The approach above is what is known as DYI dependency injection in the Java world. It's totally valid as DI is just a design pattern. But not very common because it does result in a lot of boiler plate code and it's a bit of a PITA to manually wire things up (not to mention error prone).

In the Java world, frameworks such as Spring provide a lot of DI infrastructure that has evolved to require less and less boiler plate. Combined with modern languages such as Kotlin, there is now a lot less need for stating the obvious than ever before.

Simply having a class with a constructor that takes arguments and a single annotation tells Spring "This is a bean, please construct an instance and pass it to places where it is needed as a dependency. It needs other beans to work as well. The names of those beans are the constructor arguments". If you then define those other beans in the same way, Spring takes care of all the plumbing, new calls to constructors of all the beans it has identified, configuration injection (with different profiles, default values, override mechanisms, etc), bean graph validation (no cycles, everything needs to resolve, etc) and then fires the whole thing up.

With stuff like Spring Boot, there is almost no code involved at all and you get a lot of things self initializing using sane defaults simply because the library is on the class path. I've coached a few frontend engineers dealing with some Spring Boot code. I wouldn't go as far as to say that they like it but they were all able to get productive pretty quickly.

Something like Spring is missing in the Javascript world and given the sorry state a lot of js projects end up in, it is actually needed. I see why code such as above is necessary. It's clearly better than the traditional spaghetti code approach (which, lets face it, is the common alternative). But it still looks like a lot of boiler plate to me to write, maintaint, test, and debug. And you don't even get typesafety with that. This just begs some decent automation and a bit more systematic approach to enforcing sane architecture. You get bits and pieces of that if you use react or similar frameworks but it requires a lot of discipline and expertise to stay on top of things.

Christian Bewernitz • Oct 26 '17

I recently discovered that I can use ES6 default value for parameters to by default use the method that has the proper implementation, and injecting something else when needed. It goes at the end of the list of parameters, so it doesn't need to be provided.

Does anybody see any possible problem with that approach?

K • Oct 26 '17

Could you provide an example?

Christian Bewernitz • Oct 27 '17

Lets say you have this amazing util function that looks up some data in some static/global read only Map and does some calculation that you need in many places in your code base, lets imagine the following signature: function wow(number): Metric.

In some other function foo in a different module I'm doing the following to be able to use it easily, but still be able to pass a mock or stub when I want to unit-test foo without invoking wow.

In TypeScript this could look like this:

import {wow as wowGLobal} from '../../[...]';

function foo(data: PayLoad, wow = wowGlobal) {
  const metric = wow(data.x);
  [...]
}

Is this helpful?

K • Oct 28 '17 • Edited

Ah, got it.

I probably would have implemented with a curried function.

const createFoo = wow => (data: PayLoad) => {
  const metric = wow(data.x);
  ...
}

in the regular place I'd use

foo = createFoo(wowGlobal);

and for testing something different, but I guess your way works too, it's just a bit more implicit.

Anton Vynogradenko • Jan 17 '19 • Edited

To be annoyingly pedantic, createFoo above is not a curried function, because it can't be called like createFoo(wow, data) and like createFoo(wow, data) at the same time, it's a higher order function with aurity of 1

K • Jan 17 '19

I allow it!

Jo • Dec 23 '17

Thanks for this good article.

I coded my own JavaScript Dependency Injection Framework called Di-Ninja
github.com/di-ninja/di-ninja

It's full featured and is currently the only one in javascript, as I know, that implement the awesome Composition-Root design pattern,
helping you to keep all things decoupled and to wire application components and config at one unique root place.
blog.ploeh.dk/2011/07/28/Compositi...

It work well with NodeJS and Webpack

Any feedback would be appreciated

Jonathan ES Lin • Sep 20 '18 • Edited

Hey Jo, di-ninja looks very promising. Curious as to why you decided to code your own vs. bottlejs, InversifyJS, etc. out there?

Jo • Sep 20 '18

Hey Jonathan,

thanks for your interest,

bottlejs is just an enhanced registry design pattern used as a factory and service locator, and InversifyJS provide only one of the two approach offered by Di-Ninja: the decorator approach. This approach, like the implicit strategy behind bottlejs and many others DiC, encourage coupling between the components of your application and the DiC library itself, and, only for the decorator approach, the decoupling between component rely on arbitrary interface or name.

Di-Ninja is the only one that offer Composition-Root design pattern, allowing

full decoupling between component: all exported components are factories that will only expect parameters
full decoupling from DiC: that means you can totally implement Di-Ninja as a top overlay without needing to rewrite any of your components (off course you'll have to remove singletons anti-pattern and replace them with factories if your goal is to make a clean design), your components doesn't need to know anything about Di-Ninja, only expect their own dependencies as parameters variables, and you can remove totally Di-Ninja and replace it with a raw Composition-Root, you'll have more code and it will be less readable but you can preserve the top overlay architecture, so Di-Ninja encourages you to best-practice by a REAL Inversion of Control paradigm

Another point is that InversifyJS require TypeScript, Di-Ninja can work with TypeScript, Babel (my preferred), and even without an application level transpiller, and it work fine on NodeJs, Browser (tested with webpack) and recently with React-Native environnement.

And there is many other features offered by Di-Ninja in the context of Composition-Root design pattern paradigm, but I will not list them all here, take a look on full documentation github.com/di-ninja/di-ninja to discover them ;) .