realm-js icon indicating copy to clipboard operation
realm-js copied to clipboard

Better handle object property comparison/equality/identity

Open alazier opened this issue 10 years ago • 4 comments

If you get a non primitive property it will not be the same object that was set. From @appden :

it would be ideal for objects (i.e. non-primitive values) to survive a roundtrip. Right now the getters look like they always return a new JS object, which will inevitably cause unexpected weirdness in JS code, especially now that we have native Map and Set collections. As long as each object in Realm has a unique identifier, I think this will be relatively easy to achieve

alazier avatar Sep 23 '15 08:09 alazier

I'm not sure this will be possible to do, but at a minimum it would be nice if == worked for all object types even if === does not.

alazier avatar Sep 23 '15 08:09 alazier

I'm almost positive there is no way to override == behavior for object comparisons. Do objects inside a Realm have some kind of unique identifier so we could track live objects exposed into a JS context? When I built a JS-ObjC binding, I accomplished this thanks to each object's "unique identifier" being its pointer. :smile:

appden avatar Sep 23 '15 09:09 appden

We discussed last week that this would be possible for objects that have a primary key, since we can use the value of the primary key to track live objects in the JS context. I prototyped this in PR #118, and it works, but doesn't yet support changing the primary key on an object.

I believe this is more than just a "nice to have" since we cannot override == and object hashing like we can in the ObjC and Swift bindings (I know ObjC uses -isEqual, not ==, but that fits with how Cocoa works). Those bindings only support equality for objects with primary keys as well, so I think that a valid enough precedent for the JS binding to work similarly rather than blocking this issue on some future object id support in core.

Adding this would not only benefit us from having a functional == for primary-keyed objects, but would also allow for them to be used with Array.prototype.indexOf (and friends) as well as with Maps and Sets.

appden avatar Nov 04 '15 01:11 appden

We are going to add some kind of unique id in the near future, so we should wait until it has been introduced in core/sync.

kneth avatar Dec 05 '19 12:12 kneth