-
Notifications
You must be signed in to change notification settings - Fork 16
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Records compare equal to Maps #37
Comments
Well, that sucks :-) I agree with you, If it is not, this needs fixing. I'm afraid the stringly equal way might not be very robust: I have seen times when the string output of 2 // Either both are Maps or none of them are
Immutable.is(a, b) && Immutable.Map.isMap(a) === Immutable.Map.isMap(b) If one is a What do you think? |
That wouldn't work deeply - it might be best to fix this upstream in Immutable, Lee has since said he'd be ok with that. |
Right, it wouldn't... Sure, that'd be better if this can be fixed upstream. In the meanwhile, a temp quickfix or a note in the README might help further users of Also, I'm not sure about |
They're similar, but I'm unsure if they have all the methods. I also don't really use records, this only came up because of a PR into my transit lib - @corbt is probably best placed to advise. |
Records do implement most of the same methods as maps (although I'm not sure about all of them), plus the ability to access the defined fields using property access syntax ( However, semantically they're very different. In a codebase that uses both records and maps, I would expect a record to be used for anything where the keys are defined and finite, and a map to be used anywhere that the keys are unknown/dynamic. A Obviously an immutablejs map can be used for both use cases, but in a codebase that includes both records and maps I would expect the distinction to hold. So this is a long way of saying that if I'm expecting a |
Hey guys, what is the expected behavior in this case? var z = Record({a: []});
var a = new z({a: [1]});
var b = new z({a: [1]});
expect(Immutable.is(a, b)).to.be.true; // false var z = Record({a: ''});
var a = new z({a: '1'});
var b = new z({a: '1');
expect(Immutable.is(a, b)).to.be.true; // true Thanks! |
@renanvalentin This isn't really related to this repo, as you're using The behaviour you're seeing is correct though - normal javascript arrays are compared by identity - not by value. If you want to compare an indexed collection by value you'll need to use an immutable List instead of an array. |
Hi @glenjamin, Thanks for your explanation! I'm using chai-immutable in this and it was failing: var z = Record({a: []});
var a = new z({a: [1]});
var b = new z({a: [1]});
expect(a).to.equal(b); // false But I've solved it changing the array to a var z = Record({a: List()});
var a = new z({a: List([1])});
var b = new z({a: List([1])});
expect(a).to.equal(b); // true |
Hey @glenjamin, @corbt, and @renanvalentin! I know it's been an awful while, but trying my luck still: does any of you want to further help with this? 🙏 |
See original discussion here:
glenjamin/transit-immutable-js#13 (comment)
Notable points:
And this is currently by design: https://twitter.com/glenathan/status/688050710047539200
I think it'd be useful to provide a way to opt into a stricter comparison in
chai-immutable
. I'm unsure whether or not I think it should be the default at this point.One suggested approach is to say that immutable object should be both equal, and stringly equal - as records include their names in the string output. This doesn't handle records with the same name though - so perhaps it would need something more complicated.
/cc @corbt
The text was updated successfully, but these errors were encountered: