Author: Ben Teese

Rich Object Models & Angular.js: Memoization

In my previous post on getter methods and Angular.js I showed how complex calculations can be hidden behind simple Javascript properties. One downside to this technique is that we can start to get a little blasé about when calculations are actually being executed. This can in-turn lead to performance issues. In this post I'm going to talk about expensive calculations in rich object models - be they hidden behind getter methods or just regular methods - and how we can use memoization to reduce the impact that these calculations have on performance. Memoization isn't something that you should use all the time, but for use-cases involving long chains of calculations it can be an effective optimization technique, especially within a framework like Angular. If you don't feel like reading, you can always jump to the part of my ng-conf presentation that covers memoization, or go straight to the Github project. Either way, I'm assuming that you're familiar with the foundational concepts I introduced in the first post in this series.

Rich Object Models and Angular.js: Getter Methods

[caption id="attachment_5153" align="alignnone" width="384"] Sadly not all getters can be giant robots[/caption] In my earlier posts on Rich Object Models and Angular.js and Angular Identity Maps I've shown how, by introducing a rich object model to your Angular.js application, you can begin to employ more sophisticated techniques for modelling your business domain. In this post I'm going to demonstrate how we can simplify business logic by using getter methods to hide complex calculations behind properties. Furthermore, we'll do it in a way that slots in nicely with our existing rich-object model. If you don't feel like reading, you can check out the section of my ng-conf presentation that covers this or go straight to the Github project.

Rich Object Models and Angular.js

[caption id="attachment_4953" align="alignnone" width="640"] Another sort of rich model[/caption] Angular.js is deliberately un-opinionated about how you should structure your data models. Whilst it lays out very clear guidelines for directives, controllers and services, it also makes a selling-point of the fact that it can bind to plain-old Javascript objects with plain-old properties. Services are singletons, so it can be unclear as to if and how you can group per-object state and behaviours.  Consequently, people tend to fall back to services that deal in very simple JSON objects - i.e. objects that contain only data, not behaviour. However, building the sorts of rich interfaces that our users demand means that we sometimes need to more fully leverage the MVC pattern. Put differently, for some problems it can be useful to have a rich object model that provides both data and behaviour. Recently at ng-conf, I presented a simple approach I've used for using rich object models with Angular.js. This technique leverages existing frameworks, maintains testability, and opens up a range of possibilities for more succinct and easy-to-understand code. In this post I'll outline the underlying approach, but you can also find some (very simple) helper code here.