Skip to content
Switch branches/tags

Latest commit


Git stats


Failed to load latest commit information.
Latest commit message
Commit time

Immutable state management in Ember

This is a crude todo app.

You have to fiddle with it for a while: create new todos, edit existing, delete, create some more, etc. Then use the slider to switch between states you just produced.

Read the post to the right for details.



Hey. @lolmaus here.

Throughout the last year, every JS meetup got me increasingly bored with the hype around React and related "architectures" like Flux, Redux, Reflux, etc.

From a characteristic reactboy's perspective, one of the most important React features is that all the application state is stored in a single enormous plain object, which can be immutable. On every user action, a new state object instance is produced. By not throwing previous state object instances away, you can efforlessly implement undo-redo functionality.

Some reactboys are so hyped on this that they literally consider the React paradigm to be the only "true" way to develop interfaces. Ember's OOP paradigm in their eyes is inherently broken.

What's this

On the recent MoscowJS meetup, the brightest demo of React immutability virtues was a TodoMVC app that saved previous states and allowed switching between them with a slider. By steadily dragging the slider you could see all your edits sequentially (dis)appearing.

I decided to implement the same thing in Ember to demonstrate that immutable state management in not a feature specific to React.

I didn't put much effor into it, made it over an idle Saturday afternoon. The whole thing is only about 150 lines long (with up to a half of 'em being non-meaningful lines). I spent more time on building the todo functionality. Was too lazy to use a TodoMVC boilerplace, so no good looks.

How it works

It consists of a service to manage states and a mixin to let models records notify the service of changes. If you don't include the mixin, you can instead manually configure a model to poke the service when necessary.

The implementation should work with any Ember Data models and you don't need to customize anything in your app.

But keep in mind that it's just a quick proof of concept. It will blow up users' RAM if you use it in production.

What can be improved

The implementation is naive: it watches for every attribute or relationship change. When a relationship changes, Ember does its relationship bookkeeping, producing intermediate states. Those intermetdiate states should be filtered out. Currently only a very crude check filters out a certain invalid intermediate state and leaves the rest.

Currently the service assumes that the application serializer is JSONAPISerializer. It should use JSONAPISerializer regardless of application serializer.


Immutable state management in Ember (proof of concept)






No releases published


No packages published