Manage Application State with Immutable.js
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.
[00:03] 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.
[00:15] 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.
[00:32] 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.
[00:53] 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.
[01:11] 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.
[01:30] 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.
[01:43] 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.
[02:05] 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.
[02:27] Really, it actually still remains as todo1 and that's what we would expect it to be. It cannot change out from underneath us.