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.
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.