AngularJS, Dependency Injection, and when is a singleton not a Singleton?
The Singleton is the Highlander of design patterns. There can be only one.
An example of a Singleton implementation might look something like this:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19
Singletons have some use cases, but it is generally considered poor form to use them. They are especially bothersome when you start trying to unit test your code. They effectively create global state, and shared state is a real pain to manage when you are writing unit tests.
It is extremely handy to only have one instance of a thing within a certain context, so how do we gain the benefit of a Singleton, without the pain?
Dependency Injection (DI)
Dependency injection is a lovely thing. It can be accomplished in several ways, from simply passing arguments into a constructor, to full blown DI containers like Guice, SwiftSuspenders, and AngularJS. I’m not going to go to deep in this post, but here is one from the archives that is still relevant (if you don’t mind a little AS3). Here are a couple of awesome talks from Miško Hevery that I highly recommend.
Most containers have a mechanism for providing context-based singletons.
With a DI container, we have contexts. In the case of AngularJS, we have the application module, which provides the overall container for a given application. Within this container we define dependencies that can be liberally injected into other actors within the module, such as directives, controllers, and/or utility classes. The module and its sub-modules are the context.
Here’s a very typical line of config code in an AngularJS application. This configures
a service for
mySingletonThing is a
singleton, but it is not a Singleton.
MySingletonThing does not enforce its
singleton nature. We can create as many instances as we desire. We won’t, but it
is nice to have freedom. ;)
Instead we rely on AngularJS’s ability to inject dependencies.
1 2 3 4 5 6 7 8 9 10
When we talk about a context-based singleton, these defined dependencies
are what we mean. Within a given context the DI container will only allow a single
instance of the object to be injected. The object itself does not protect
against or prevent multiple instances. You can
new it all day long,
and there will be no complaints. With objects managed by a DI container you
should never need to use
new for objects that are injectable.
This provides you with all the benefits of a Singleton, with none of the sadness. Now when you write your units tests, you can use as many individual instances as you might need, without managing global state. Joy.
With Angular’s DI implementation, we are a bit limited. Within a given module, we only have access to a single context. This limits some flexibility that would be gained by allowing nested contexts. Consider for example a user with multiple accounts. What I’d really like is for each account to represent a context that could have its own singleton objects. It would be very handy to dynamically add/remove account sub-modules from the user. The singleton injectables defined in the user module would cascade to sub-modules, but a sub-module could also define its own singleton mappings, perhaps even overriding the parent module’s. I don’t know if this is on the roadmap, but it would be awesome to have a more robust injector.
A Singleton is a singleton, but a singleton is not always a Singleton in the formal sense. The enforced Singleton is generally regarded as “to be avoided”, but context-based singletons are an extremely useful tool that play nice and don’t represent hairy global state. YMMV
You can find me on twitter @jhooks, google+, or via email firstname.lastname@example.org
I will never spam you. Unsubscribe at anytime.