Become a member
to unlock all features

Level Up!

Access all courses & lessons on egghead today and lock-in your price for life.


    Manage Application State with Immutable.js

    J.S. LeonardJ.S. Leonard

    Learn how Immutable.js data structures are different from native iterable Javascript data types and why they provide an excellent foundation on which to build your application's state.



    Become a Member to view code

    You must be a Member to view code

    Access all courses and lessons, track your progress, gain confidence and expertise.

    Become a Member
    and unlock code for this lesson




    Immutable.js is a library from Facebook that provides a series of immutable data structures like List, Stack, Map, Set, things that are iterable that look a lot like arrays and feel like hashes and things like that.

    Instead of them being mutable, they're always immutable, meaning they don't change from underneath you. The reference to them can change, but the data inside them cannot, which means you can build predictable and reliable state models on top of them. It becomes a lot easier to manage your application's state.

    I'm going to show you what I mean by this. I've got a couple of tests set up here that I want to show to demonstrate. In this first test, we should see a side effect when mutating this original array. We have our application state. We've added two toDos to it. We passed a reference of this state to this variable right here.

    This could be a big problem. If this reference gets passed around, that state can change from underneath us. Let's go ahead and do that with this mutateValue function that I have up top, which basically will take a position and update it at that place.

    Now, we've mutated the value. mutatedState is mutated, but our original state, we should expect that to be the same. Let's see what position one looks like on state. It should equal our todo1. It doesn't. We've got an assertion error.

    Todo1 does not equal newTodo, because this mutatedState, this reference that we passed, has now updated and changed the original. That's no good. What if it updated to null, and we were relying on that? We'd have a runtime error.

    Immutable.js operates a little bit different. We have a list structure here that is getting passed in an array of the same data up top. That's how basically you can instantiate a list. Now we have another structure, a second state, that's referencing the first one. Let's go ahead and do the same thing.

    We'll write an updateState function. We'll go ahead and update the state and see what happens. We'll do the same thing, newTodo, and see what happens. We should expect, just like the first test, that immutableState, the first one, .get(0should equal newTodo.

    Really, it actually still remains as todo1 and that's what we would expect it to be. It cannot change out from underneath us.