\n
\n
\n
![\"\"](\"http:\/\/lh4.ggpht.com\/-10FMqvR6ia8\/U682poi2cQI\/AAAAAAAABQY\/pLj4kmg3hx4\/chimera3sm_thumb%25255B7%25255D.jpg?imgmax=800\" "\\"chimera3sm\\"")
<\/a> \u201cWell, Dimitri, every search for a hero must begin with something every hero needs, a villain. So in a search for our hero, Bellerophon, we have created a more effective monster: Chimera.\u201d \u2013 <\/em>Dr. Nekhorvich, Mission Impossible II<\/em><\/strong><\/p>\nI don\u2019t believe I created a monster, but in my search to understand JavaScript dependency injection, I did create jsInject<\/a>. This library acts as an dependency injection container for JavaScript components that depend on each other. It is based on constructor injection<\/em> which inverts control of dependencies by passing them in through the constructor. If you are looking for dependency injection in JavaScript without taking on a full framework, this is an extremely lightweight solution that should do the trick for you.<\/p>\n For example, if your serviceA depends on dependencyB, you might define it like this to return it from a factory:<\/p>\n Another approach is to use a constructor function. This is required if you use a class-based approach, as code generated from tools like TypeScript doesn\u2019t lend itself well to the factory pattern.<\/p>\n Of course there is always the self-invoking function as well:<\/p>\n In all of these cases, the dependency is injected and the purpose of a dependency injection container is to handle that injection for you.<\/p>\n A logical first question is: why bother? I often hear this from developers and architects who are concerned that dependency injection adds unnecessary overhead and overcomplicates projects. More often than not they have worked on smaller projects with smaller teams and might not have run into the sheer size of project that benefits from dependency injection. I\u2019m used to projects where there are tens of thousands if not hundreds of thousands of lines of client code (yes, I\u2019m talking just the JavaScript part) with hundreds of components that interrelate. Forget module loading, bundling, etc. for a moment (worrying about how the scripts get loaded in the first place), let\u2019s take a look at common problems:<\/p>\n The most basic DI solutions provide at least two features: the ability to register a component, and the ability to retrieve an instance of a component. Advanced solutions will allow you to intercept requests, override methods on the fly, register multiple components that satisfy a given interface and even manage the lifetime of a component (whether you get a new instance or the same one each time). The registration is key because that tells the container what you expect to retrieve, and somehow the container must also understand what dependencies to provide.<\/p>\n A naive implementation will use the constructor parameters to determine dependencies. I call this naive because naming a parameter doesn\u2019t imply the dependent component has the same name, and when you minify or uglify your JavaScript code you lose information. A more common approach is to annotate the component somehow. I really like the options that Angular provides for annotations. When you register a component, you give it a name that doesn\u2019t necessarily have to match the name of the constructor function or the function being called as a factory. When you annotate a component, you simply provide a list of names of dependencies. There are two ways to do this. You can either mark these up on the component itself by exposing a property as an array, or you can pass these in to the container when you register it.<\/p>\n Let\u2019s register a component. For jsInject I decided to mirror Angular\u2019s approach and allow you to either pass dependencies at registration time, or use a static property. Here is an example of providing the information at registration time:<\/p>\n In this case the dependency passed in as \u201cecho\u201d to the constructor is registered as \u201cechoFn\u201d to the container, and the function we are registering called fn is named \u201c1\u201d in the container. The registration expects an array. The last member should always be the component we are registering (whether it is a constructor function or factory) and the members before it are the names of the dependencies in the order they will be passed in.<\/p>\n The other approach is to annotate the component. Here is an example of using the annotation approach. This service exposes a hard-coded static property called $$deps to list the dependency names:<\/p>\n It is registered like this (notice there are no \u201cannotations\u201d added to the registration array, just the constructor function itself):<\/p>\n jsInject creates a method for instantiating the component but does not try to invoke it right away. It is a lazy-loading function. The first time the component is needed, it will instantiate it, then it will return the same copy for future requests. Here is the general pattern \u2013 we\u2019ll expand the magic part, but note how once it\u2019s done, it won\u2019t go through that work again because the function replaces itself with a new one that simply returns the instantiated component.<\/p>\n So how exactly does it wire up the dependencies?<\/p>\n The magic is in walking through the dependency chain. The algorithm itself is fairly simple. You basically iterate the list of annotations, grab them from the container recursively, and shove them into a list of arguments that you\u2019ll pass to the component\u2019s constructor. If an annotation has been instantiated, it is returned, otherwise it is also scanned for its own annotations and so forth. The trick is understanding the format of what was passed in and generically instantiating it with a dynamic constructor list.<\/p>\n The level keeps track of recursion to avoid infinite loops. You can tweak this as needed but I\u2019ve seldom seen well-written systems go more than a few levels deep (for example, a controller may depend on a service that depends on other services). The dynamic nature of JavaScript makes it easier for us to build a component on the fly. First, we create an empty template:<\/p>\n Next, we get the component itself (which is a function, but it might be a constructor function, a factory, or a self-invoking function):<\/p>\n Then we grab the annotations for the component. Remember, the last element of the array is the component itself. If the array has more than one element, we assume the previous elements are annotations. Otherwise, we check the component itself for the $$deps property, and failing that we assume it has no dependencies.<\/p>\n Now for the magic, we copy the prototype of the supplied component to the prototype of our template:<\/p>\n Then we create an instance of the template:<\/p>\n Finally, we call a recursive invoke function to push in dependencies. If there are none, we use the instance we created, otherwise we use the fully wired result from the recursive call.<\/p>\n The recursive call simply checks the recursion level to make sure we haven\u2019t gone too far, then iterates through the dependencies. Each dependency is pushed into an arguments list (as an instance that is also recursively retrieved from the container itself). We use the function to apply to the template we created with the arguments we\u2019ve pushed.<\/p>\n Voila! Now we are able to retrieve a component with its dependencies. Here is an example of wiring up multiple components, some of them by annotating during registration and others annotated using the $$deps:<\/p>\n You can see a full working example with this fiddle<\/a>. Be sure to open your console log, that is where you can verify the call to the course map returns an expanded instructor and course but all dependent components are only created once even though they were registered in a different order.<\/p>\n You can certainly improve the implementation (and I do accept pull requests). As an exercise, for example, how would you modify it so you could store constant values and not just instances of objects? In other words, what if I want to register the text \u201cCopyright 2014\u201d in a value called \u201cCopyright\u201d? Also, the current implementation for registration doesn\u2019t implement chaining. Instead of ioc.register(x); ioc.register(y) it would be far more convenient to chain like this: ioc.register(x).register(y) \u2026 do you know how to fix it so that\u2019s possible? What about a modification that allows you to determine whether you get the singleton, cached instance vs. force a \u201cfresh\u201d instance when you request it? (Hint: take a look at my Portable IOC<\/a> project that supports this in C#).<\/p>\n As you can see, dependency injection itself is fairly straightforward and is designed to simplify your solution, not overly complicate it. Angular adds some extra caveats and shortcuts to their solution but in essence it behaves very similar to the example I\u2019ve provided here. In fact, I hope by walking through this you can now go back to the Angular source and better understand what is happening in the $inject implementation. If you are able to use the jsInject<\/a> component in your projects that\u2019s an added bonus, but otherwise I hope you walk away feeling much better about using dependency injection and specifically how it can be implemented in JavaScript.<\/p>\n * Chimera image credit goes to AKHSMythology<\/a> under the Creative Commons Attribution Share-Alike 3.0 License<\/a>\r\nfunction serviceA(dependencyB) {\r\n return {\r\n id: dependencyB.getId()\r\n };\r\n}<\/pre>\nfunction ServiceA(dependencyB) {\r\n this.id = dependencyB.getId();\r\n}<\/pre>\nvar ServiceA = (function() {\r\n function ServiceA(dependencyB) {\r\n this.id = dependencyB.getId();\r\n }\r\n return ServiceA;\r\n})();<\/pre>\nWhy Dependency Injection?<\/h2>\n
\n
![\"\"](\"http:\/\/lh3.ggpht.com\/-ZhKVA__Alwc\/U682qvtt5iI\/AAAAAAAABQo\/BB00ulgS5iM\/hero_thumb%25255B2%25255D.jpg?imgmax=800\" "\\"hero\\"")
<\/a> I believe there are many benefits and that DI itself is only as complicated as you make it. In my experience, it simplifies things on larger projects.
\n
\n <\/p>\nDependency Injection to the Rescue<\/h2>\n
Registering the Component<\/h2>\n
var fn = (function() {\r\n function Fn(echo) {\r\n this.echo = echo;\r\n this.test = function() {\r\n return echo.echo(expected);\r\n };\r\n }\r\n return Fn;\r\n})();\r\n$jsInject.register('1', ['echoFn', fn]);<\/pre>\nfunction ServiceB(serviceA) {\r\n this.id = serviceA.id + 'b';\r\n}\r\nServiceB.$$deps = ['ServiceA'];<\/pre>\n$jsInject.register('ServiceA', [ServiceA]);<\/pre>\nvar _this = this;\r\nthis.container[name] = function (level) {\r\n var result = {}; \/\/ magic goes here\r\n _this.container[name] = function () {\r\n return result;\r\n };\r\n return result;\r\n};<\/pre>\nRetrieving the Component<\/h2>\n
Template = function () {}<\/pre>\nfn = annotatedArray[annotatedArray.length - 1],<\/pre>\n
deps = annotatedArray.length === 1 ? (annotatedArray[0].$$deps || []) :\r\n annotatedArray.slice(0, annotatedArray.length - 1),<\/pre>\n
Template.prototype = fn.prototype;<\/pre>\n
instance = new Template();<\/pre>\n
injected = _this.invoke(fn, deps, instance, lvl + 1);\r\nresult = injected || instance;<\/pre>\n
for (; i < deps.length; i += 1) {\r\n args.push(this.get(deps[i], lvl + 1));\r\n}\r\nreturn fn.apply(instance, args);<\/pre>\nfunction main () {\r\n var ioc = new $$jsInject();\r\n ioc.register('courseMap', [CourseMap]);\r\n ioc.register('instructors', ['log', 'ch', Instructors]); \r\n ioc.register('courses', ['log', 'ch', Courses]);\r\n ioc.register('log', [Log]);\r\n ioc.register('ch', [CollectionHelper]);\r\n ioc.get('log').log(ioc.get('courseMap').getCourses()); \r\n}<\/pre>\nImprovements<\/h2>\n
Wrapping Up<\/h2>\n
\n* Hero image credit Office ClipArt<\/p>\n