Thursday, September 26, 2013

Compose, don't inherit (not a lot anyway).

Lately I've seen a lot about JavaScript Inheritance and in particular different github projects that allow you to do inheritance in a certain way. Most of these solutions are about trying to use some form of classical inheritance and with good reason. If you're used to any other language then that is probably what you learned and so it makes sense. Also there can be performance gains as using a "class" means you won't be mutating an object's signature and as such a JavaScript runtime can make optimizations for that "type".

There are also some good articles about what JavaScript inheritance is really about and if you only read one, make sure to read Kyle Simpsons: JS Objects.

But do we really need long inheritance chains where we link up lots of objects and have lookups going up a chain? As JavaScript is so flexible can we learn things from Functional and Aspect Oriented styles of programming? I think we can.

At Dataminr we've begun the journey of rewiring (it's like rewriting from scratch but using most of the old code, putting it in different places and changing how it's all passed through) our code. It turns out that combining some ideas gives us an easy way to keep a flat inheritance structure where we can compose together objects that we need. To do this though we have to take functionality away from the objects and put them in services that we can pass our objects in to, split some objects apart and with the rest cut them in to little packets of functionality that can be added when necessary. This leaves us with simple objects and a toolbelt of features we can add on as needed in the main file - we get closer to configuring a product rather than actually coding it.

We're currently using Backbone.Advice which I introduced in this blog post. Since starting with that we've learnt a lot about how to structure the application using the AOP approach. Instead of having the inheritance through the constuctors we moved most inheritance over in to the mixins. From the original blog post I mention that you can build ever more complex mixins by adding in other mixins. Doing this we can do things like make a clickToSelect mixin that will call upon the clickable and selectable mixins.

But won't all these mixins get in each other's way and run when they're not supposed to? Perhaps the most important thing when using these mixins is a naming convention. Inside the Backbone.Advice repository there is a mixins.js file that gives some examples in to using mixins. I wouldn't go ahead and use these in production as they're a bit stale from the version we use in production, but looking in to them you can see there is a very deliberate naming convention. We use very simple, very clear names that describe the current action precisely. We do something similar with the options that are passed in to the mixin (as all mixins will share a common options object). For instance we decided there would only be one scrollable element per view so whenever a mixin needs a handle to the element it exists as options.scrollEl - no matter which mixin needs it.

The one thing that we kept coming up against though (as we still have legacy code being used) is that older classes that extend from these base classes were overwriting functions. Sometimes we wanted to overwrite the base function but we always wanted to keep the mixins applied. To fix this we had to come up with a new way of defining the inheritance. So after all this I get to introduce Backbone.AdviceFactory.

Now all we do is register how something is built by defining it's base (if it's been registered before you just call it's string name) and we can go ahead and add in all the functionality through extends or mixins (though it will automatically put functions as "after", extend existing objects and clobber everything else) and the factory will go back through all the bases, work out the extends and then put the mixins on last. This means all the mixins are kept. We can then Instantiate the object through the factory.

It might be better to see an example - I've commented the code so you can see how it works:

It's an incredibly powerful way of defining objects. As we write more we tend to find that more functionality can go in to mixins and these structures get a lot flatter, and with a lot less functions given to the factory. The functions mostly come from the mixins and only configuration goes in to the objects (though most of that is passed through at instantiation).

The last piece of advice (no pun intended) we could give is that you will come up against recurring structures in your code. Perhaps you have a widget that will always have a list that will always have a header. To deal with these we create factories that will do all the instantiation for you and wire up everything that needs to talk to each other, just pass in the data and any constructors that are different to the default. This leaves us with simple units we can call upon and just pass in the data. We do all this in the main file so all the data is available to use meaning we can setup complex relationships without having to jump through hoops.

I hope this helps some people out there - we've been using this approach and it works extremely well. It has allowed us to cut down on our development time and spend more time at the pub - which really is what development is all about.

If you find yourself wanting to go back to remove items from the chain then you're probably applying things too early in the chain. Keeping the chain as shallow as possible will help and only applying things when you need them.

As for duplication of functions, you could declare a function outside your mixin and use a reference so it points to a single function, but in the complex applications I have used this with I haven't seen any performance issues (I have had some objects with over 20 mixins on and that would have a function decorated with more than 6 levels or arounds that would be used over 100 times on the page with other things - approx. numbers off the top of my head).