While Immutable.js offers .is() to confirm value equality between iterables it comes at the cost of referencing each key and value in both objects. For lightning fast equality checks, Immutable.js can produce a hash code based on an iterable's content. If two iterables have the same content, their hash codes will be the same. It's worth noting that this technique is unsuitable for mission critical application development since there is a chance, however slight, that checksums like these might collide. This is outlined here: https://en.wikipedia.org/wiki/Collision_(computer_science)
I want to show you a neat little technique that I stumbled upon when trying to compare two large data sets. While Immutable.js offers is to confirm value equality between the iterables, it comes at the cost of referencing each key in value in both objects.
For lightning fast equality checks, immutable.js can produce a hash code based on an iterable's content. If two iterables have the same content, their hash codes will be the same. It's worth noting the technique is unsuitable for mission-critical application development. Since there is a chance, however slight, that check sums like these might collide. This is outlined here in their documentation and points to Wikipedia.
Let's take a look in how to do this since it's such a useful technique. I've got my To Do class. I've got this function that will generate To Do's. We're going to go ahead and create two different immutables, two different immutable lists. We're going to compare them.
Let's do VaR. To Do's equals generate To Do's. We've got a series of To Do's being pushed to an array. We can create out iterables based off this now. We'll do, let To Do's1 equals immutable.list.of and To Do's. We'll do the same thing for another one.
To Do's 2. We should expect these are two different objects, they might not equal each other. Expect To Do's1 to not equal ToDos2 because these are holding different places in memory and that's pretty much what that's checking. They're two different objects.
However, they are, for all intents and purposes, equal. Is would work here, but we'd also come at a performance cost if we generated quite a few To Do's. What we're going to do is this. We're going to do, expect To Do's1.hashcode. It's going to generate a hash code for To Do's1. It checks them. I want to see if that is equal to To Do's 2.hashcode. We spelled that correctly.
Sure enough, we have it. You can actually cache this hash code now and reference it for future objects. It's a super fast way for checking things.