Support reference comparison about chai-immutable

[astorije]

Gotcha, thanks for the clarification!

Agreed, let's go with to.referenceEqual, at least while in v2, and if it needs changing in the future, it could be done in v3. But in the meantime and if possible, I'd rather keep .to.equal as a value equality check since it's more in the spirit of Immutable.js.

Thank you both for your help, looking forward to a PR! :)

[jakubzitny]

Sure -> #218 😉

[astorije]

Hey @jakubzitny! Thanks for your feedback 🙏

I am totally open to a PR (I promise I will review it faster than I replied to your issue 😅). I prefer the option that maintains parity with the core of chai as this is pretty much what this plugin tries to achieve.

Wanna help? :)

[astorije]

Actually, thinking more about this, I think .to.equal should stay the way it is because that's more in line with what Immutable.js is.
I think comparing references is an edge case in the world of Immutable.js (may I ask you for a use case?) so it would be unfortunate to tie it to the default meaning of .to.equal I think.

At the end of the day, assuming a and b are Immutable.js object, it shouldn't matter if expect(a).to.equal(b) ensures the references are the same, it's all value-based. Maybe not being able to assert reference equality is a sign that something might be fishy in the specs, but if there needs to be an escape hatch, then an explicit .to. referenceEqual is probably more appropriate. I'd be curious about use case before having a definitive opinion however.

[jankuca]

Our use case is covering shallow compare compatibility of our state. We have a store which returns a Map for instance and we want to ensure that it returns the same map instance on multiple invocations unless there were changes between getter calls. This allows us to optimize React component rerendering as the default comparison logic relies on reference equality.

[jakubzitny]

Thanks for the answers. Well, the use case is simple — I wanna be sure that a method (from flux store, a custom collection, or any class that stores Immutable data internally and returns them filtered/modified/mapped) returns always the same "modified" collection and does not re-create it on call every time (unless the data has changed).

Or as @jankuca mentioned above.

I think changing the .to.equal behaviour would be more "correct", but in order to cover most cases with Immutable.js and also to keep the backward compatibility, I would really be better to just implement to.referenceEqual.

[astorije]

Hey @jakubzitny and @jankuca, quick follow-up: do you still intend to open a PR for this? I'd be happy to include it in the next release :)

[astorije]

This has now be released as part of v2.1.0. Thanks again!