This lesson is for PRO members.

Unlock this lesson NOW!
Already subscribed? sign in

Immutable.Record() as data models

5:33 JavaScript lesson by

The Immutable.js Record() allows you to model your immutable data much like you would model data with native Javascript classes or objects. It differs from native classes because it cannot be mutated after it's creation and it always has a default value. It's an excellent construct in which to piece together your stores, be them Flux or some other storage implementation. Let's quickly create an Immutable Record().

Get the Code Now
click to level up

egghead.io comment guidelines

Avatar
egghead.io

The Immutable.js Record() allows you to model your immutable data much like you would model data with native Javascript classes or objects. It differs from native classes because it cannot be mutated after it's creation and it always has a default value. It's an excellent construct in which to piece together your stores, be them Flux or some other storage implementation. Let's quickly create an Immutable Record().

Avatar
Lee

Won't the id field be pre-computed, and identical for each new ABRecord instance?

It'd be nice for Immutable to accept a function that runs in the event that the key isn't supplied to the constructor, so this could be generated on the fly.

In reply to egghead.io
Avatar
J.S.

Hey Lee! You are right, it will be the same as evidenced in this JSBin: https://jsbin.com/hanitum/edit?js,console

It would be nice if it could accept a function to generate an ID, but for now creating a class factory is the only option. Maybe make a PR on GH? :)

In reply to Lee

The Immutable.js Record allows you to model your Immutable data much like you would modeled data with native JavaScript classes or objects.

It differs from native classes because it cannot be mutated after its creation, and it always has a default value. It's an excellent construct in which to piece together your stores, be them Flux or some other storage implementation. Let's quickly create an Immutable Record.

You can find it in the documentation. We'll go and show you how to set this up. Throughout this series, I've been using this ToDo class. It's a native JavaScript class with an ID, title, items and completed.

Well, if you want to use an Immutable Record instead, you use the Immutable name space, call the Record and pass in an object with the properties you want available to you on the Record. We have ID, title, items, and completed, just like before. Let's go ahead and compare the native JavaScript class with an Immutable Record, just to show you how this works.

To instantiate an Immutable ToDo, we're going to go ahead and use the new operator. We're going to call it "New ToDo record," which is what we created up here. OK?

Then what you do is, you just instantiate it much the same way as you created it in the first place. We'll pass in a title, we'll call it "ToDo," OK. We will give it some items, which will be an Immutable List. We'll give it item one and item two. Then we will give it a completed of true. That's how you create it.

The nice thing about an Immutable Record is, whatever you don't specify, it will have a default value. ID will have this value here. This is nice, because it gives you a predictable model that allows you to test for certain things on the object.

We're also going to create a ToDo, a regular one, like before. New ToDo, OK, just using the new operator, so it's similar in that respect. Except with the class, you just pass in the properties on the constructor. We'll say, ToDo, we'll give it an Immutable List of item one and two, in fact, we'll just copy and paste what we have here. We'll say it's true.

OK, so now, for all intents and purposes, we have two identical objects as far as data goes. Let's see if this data's the same. We're going to create a constant, call it "Data is same," and we'll say, equals Immutable ToDo.title. We'll see if it's equal to the title.

We will see if the two Immutable Lists are the same, so immutable ToDo.items and ToDo.items, OK. Then we will also check to see if Immutable ToDo.completed is equal to ToDo.completed. This will let us know if we actually have the same data.

Let's write an expectation for that real quick. Expect data is same to be true. I have misspelled this, let me fix this real quick. We have a passing test. No surprises there.

Here's where a surprise can happen and this is why it's really great to model your stores based on these records. Say ToDo not title is set to null. Now you've got a null value and if you actually try and use that, you can get a runtime error. That's a problem.

Just expect ToDo title to be null. The test passed so it is, it's not good. That could be a big problem down the road, but with records, you can't change that. You can always rely on title either being either equal to default title or however it's been instantiated, and you have control however it's instantiated.

Let's go ahead and try and change it and see what happens. We'll say Immutable ToDo.title is equal to something else, and boom, you get an error right here. Cannot set on an Immutable Record. You can't change that. It's a locked down.

What we'll do is, we'll write a test that will essentially try and change it. .ToDo, .title is equal to null. We're going to get an error. We'll do catch error and we will write an expect E to be defined. I know that doesn't quite match we have up here. But you get the idea. That's how an Immutable Record works.

Now, I want to show you how the default value works in an Immutable Record. Right down here, an Immutable ToDo, we'll create a new Immutable ToDo.Record. All we'll pass in this time is just the completed state. We'll say it's completed.

Now we should expect this immutable ToDo.title to be equal to default title. We have a passing test. You can always rely on that.

HEY, QUICK QUESTION!
Joel's Head
Why are we asking?