Decorators are not implemented in Javascript by default yet, so in this post we will try to show what decorators are, what options we have in javascript to suport them, and how to simulate them using function composition. Decorator is a structural pattern that promotes code reusage as a flexible alternative to subclassing.

Traditionally it was devised as a way to add non vital information to the object, as the vital information should be defined in the class. But, considering the gains from utilizing this pattern, that need not be so. Decorators are generaly used when number of subclasses is painfully high, or when the same potential subclass needs to be applied to various parent classes.

So, as Javascript continues to look more and more like Python, decorators are not making an exception. The official proposal for ES2016(aka ES7) offers something almost identical to python decorators, so rub your hands, we are getting them soon 🙂 The way they work is you prefix your function name with ‘@’ stating that whatever method you are decorating, is passed as an argument to your decorator. Decorator returns this function with added functionality. Decorators are helpful for anything you want to transparently wrap with extra functionality. These include memoization, enforcing access control and authentication, instrumentation and timing functions, logging, rate-limiting, and many more.

Lets look at the ES7 proposal

You can use ES7 decorators if you install

If we instantiate the class and look at its prototype, we will see that it has an isCold property. The ES7 decorators, apart from target argument accept key and descriptor, that basically override the default ones. So if you want to decorate your function in a way that no one can modify it later, you will add a @readOnly decorator to it. The important thing to note is that Until ES7 happens, apart from Babel, you can use decorators in Typescript .Typescript is a strongly typed superset of Javascript with some very nice features. The transpilers work fast enough not to pose any problems, and the overall benefits of authoring your modules / libraries / frameworks in it are huge! I know it seems like it is not in the spirit of the language and a bit of overkill, but being able to tell with certainty the types you have available is something we should strive for.

Apart from the better syntax and some low level goodies, we can simulate the main principle on which decorators operate with no problem. Basically, decorators are simply higher order functions, so if we apply the same logic, what we need to do is simply wrap our method in our decorator function. Say you want to change the size and calculate the price of beer depending on its size and default price.

As you can see, decorators are basically nothing more than function composition. Allright, ES7 implementation suggests we are sending keys and descriptors alongside target, allowing for some neat manipulation, but the principle is the same.

The same way we added makeSmall, we could add makeCold, makeBig, or any other property on our object by simply composing our functions.

If you don’t like the syntax, you can use Lodash, Ramda or any other utility library that has compose in it’s repertoire. ex: _.flowright( new Beer(), makeSmall, makeCold ) ;

That is all for now,, but note that there are numerous resources on the subject, so hit those google queries if something didn’t make sense!!


Next, lets see what is the difference between Mixins, Traits and Stamps.