Smart Front-ends & Dumb Back-ends: Persisting State in AngularJS

A state is something generated by you as you interact with a website — for example by clicking on a button, or typing some text into a text field. This state resides in your browser’s RAM and consists of JavaScript objects such as arrays, strings and objects.

In this article we’re going to dig into a pattern of taking these arrays and objects and persisting them. To do that, we’ll need some clever ways to separate the temporary “junk” from the really important stuff we can’t lose.

Getting Started

Let’s say that we have an array of objects and each object has “temporary” keys in it. We don’t want these keys to be persistent when sending the array of objects in for a persistent store (localStorage or Ajax).

In the example I’m going to show you, we’ll work with an AngularJS app. In it, we put things into each object that don’t need to be persistent. Everything that is not important to be persistent starts with an underscore.

Thinking about Storing This Persistently

Let’s now suppose that we want to persist $scope.things. It might be a Todo list that we want to come back to after having closed the tab. And when we do come back, a lot of these shallow attributes (such as _expanded or _dateAsString for example) are things we don’t want to clutter up in the persistent store. We want to do that because they can easily be re-generated or reset without losing what’s valuable. Or perhaps we’re worried about memory and some of those temporary state items are heavy.

Let’s say we want to persist it in localStorage. What we need to do look like:

localStorage.setItem('mystuff', JSON.stringify($scope.things));

However, that’s going to save a bunch of other things in the objects that we don’t want to remember (again, because they can be regenerated or because they’re simply not worth saving).

So the first thing we need to do is to clone them. To clone an array, you have to write a JavaScript code like this (I’m using ECMAScript6 here):

let copy = Array.from(myArray)

But if the array is one full of objects (i.e. dictionaries), then we have to do a little bit more magic:

let copy = Array.from(
myArray,
(item) => Object.assign({}, item)
);

In this way, we get a deep copy.

And here is our chance to modify that copy so that it’s prepared for being saved persistently. Without further ado, here’s the code that does it:

What’s With That $$hashKey Thing?

AngularJS puts a key called $$hashKey into every object that is being rendered (if it believes it needs to). In this way it can internally know what has changed and what hasn’t. There’s a built-in utility in AngularJS that we can use to strip these:

If we do repeats like ng-repeat="thing in things", AngularJS will put those keys in. But to avoid it, we can use a tracking key like:

ng-repeat="thing in things track by thing.id"

And it won’t be put in.

Either way, since we’re probably building a utility tool that we can re-use for various AngularJS constructs, it might be a very good idea to strip those $$hashKey things.

Putting It Together

Our first demo app was rather silly because you never “enter” anything into the state, so there’s no point in saving it. First, let’s change our demo application so that it actually takes input that is worth saving. The application is going to be a “week log” where you type in what you did every day of the week.

Let’s just build it first so that we have the bones working. The following is the HTML code we need:

The demo app uses localStorage for persistency. Upon loading the app it retrieves past saved stuff and if there isn’t anything there, it creates a first sample. Then, it renders the weeks and you can edit the entries. As soon as you blur out of any input field, it starts the saving process. First it modifies the state a bit (copying from the list week._days to the object week.days) and secondly it creates a deep copy clone and when it does that, it strips out all the keys we don’t deem necessary to keep. Lastly, it stores it in localStorage.

Try opening the demo app, type something, blur out of the input fields and then refresh the whole page and you should see your entered data still being there.

Persistency and Beyond

Someone might laugh at the notion that localStorage in the browser is persistent. It’s only stored in your device and if you lose the device or completely wipe your profile that storage is gone. A more persistent solution is a proper database in the cloud. One that is backed up and replicated and whatnot. However, that’s outside the remit of this article and the extension to do that is really simple. Because we store JSON in localStorage, it means it’d be dead easy to Ajax send just the stuff we want to save and you don’t have to worry about columns or types.

Obviously, if you go down the Ajax route, saving the whole big thing on ever input field change would be potentially excessive. However, since each ng-blur knows which week and week day you edited, it would be possible to Ajax send just the change for that particular day. Exercise left to you, readers.

Conclusions

Is this realistic? Yes, it is! Does it scale? Yes, it does.

We’re entering an era where front-ends are getting smarter and back-ends are getting dumber. That means that you put much of the business logic in your front-end code and ask the back-end to just perform really basic tasks (like “Just store this blob!”). If you want to build one of those fancy offline-first apps, you need to start thinking of keeping all state in the webapp and you can’t depend on the server always being available. Eventually it has to be though.

Now you need to think of the back-end as a sync server. It doesn’t mean you have to send whole blobs of everything back and forth but the last thing you want to do is have complex business logic in both the front-end and the back-end and if you want that offline-first app experience, you have to lean towards the front-end for where the magic happens.

Also, putting the business logic into the front-end and thinking of the back-end as “dumb”, it means that you can become a lot more agnostic about your back-end technology. Those back-end technologies are busy being available, backed up and fast. The demo app mentioned above uses localStorage but that would be very easy to replace with Kinto, PouchDB or Firebase. Those are all very scalable platforms. So, again, this pattern does scale.

Peter is a full-stack Web Developer at Mozilla where he works in the Web Engineering team. His passion is building fun web apps that are fast as greased lightning and has published open source software for over 15 years. He blogs and experiments on www.peterbe.com.