Add a workaround for React Native Proxy objects pre-JSI not working properly with JSC.

[tomduncalf]

What, How & Why?

As described in #4507 (comment), React Native Proxy objects which do not use JSI do not seem to be compatible with JSC – it doesn't "unwrap" them properly so can't see the wrapped type.

This means that you cannot pass a result from useQuery in @realm/react to the subscription set mutation functions, as it is wrapped in a Proxy.

This workaround stores the unproxied Results as a non-enumerable field on the proxied object, so that we can check for its presence and pass that to C++ instead of the proxied version when calling subscription set mutation functions.

Note that this problem seems to go away with JSI in v11 (regardless of whether Hermes is being used) so another option is that we just accept the issue for now, and wait until v11 becomes master

This closes #4507

☑️ ToDos

• 📝 Changelog entry
• 📝 Compatibility label is updated or copied from previous entry
• 🚦 Tests
• 📱 Check the React Native/other sample apps work if necessary
• 📝 Public documentation PR created or is not necessary
• 💥 Breaking label has been applied or is not necessary

If this PR adds or changes public API's:

• typescript definitions file is updated
• jsdoc files updated
• Chrome debug API is updated if API is available on React Native

[kneth]

My only comment is about naming of a constant and it should not block merging this PR.

[kneth]

I have some reservations about REALM_REACT_PROXIED_OBJECT - it is leaking one package to another and in the opposite direction of the dependency. Could we find a neutral name?

[takameyer]

Perhaps ORIGINAL_REALM_COLLECTION

[tomduncalf]

I went with PROXY_TARGET as per Kræn's suggestion

[tomduncalf]

Closing in favour of waiting for v11 to be released which uses JSI and will fix the fundamental Proxy issue. Workaround for now is to pass in the results directly, e.g.

const people = useQuery(realm.objects('Person'));
// ...
realm.subscriptions.update(subs => {
  subs.add(people); // this will error
});

becomes

const results = realm.objects('Person');
const people = useQuery(people);
// ...
realm.subscriptions.update(subs => {
  subs.add(results); // no error as we are passing in the Realm.Results instance directly
});

[takameyer]

Seems like a very good way to getting around this issue. I would, however, like to see a test for this so that we can ensure it still works after v11 when we remove this code.

[takameyer]

Perhaps ORIGINAL_REALM_COLLECTION

[takameyer]

Seems we are missing some linter fixes in this file

[tomduncalf]

Resolved

[kraenhansen]

I have just minor suggestions.

[tomduncalf]

Seems like a very good way to getting around this issue. I would, however, like to see a test for this so that we can ensure it still works after v11 when we remove this code.

@takameyer I like the idea of adding a test but I am struggling to think of a good way to do it, because in order to get access to realm.subscriptions, you need to have a valid sync config, which means you need a Realm app to test against. This would mean we'd need to do one of:

1. Make the Realm React tests support working with the app importer and move some of the Mocha hooks etc. used to interact with it from integration-tests into realm/common. This would be the right approach but feels like a lot of work for one test for a temporary(ish) test.
2. Make the integration tests somehow test useQuery when running in React Native. Because it's a hook, this might mean setting up a whole React app to test in. Again, a lot of work and would also be breaking the separation of concerns in a weird way possibly (not sure if the main integration tests should be testing Realm React, although you could argue it's appropriate)
3. Add some way of exposing subscriptions without a valid sync session for testing purposes, which feels quite hacky

If you have other ideas let me know though as I agree it would be good, but I'm not sure if it's worth a fairly major bit of work to achieve. I might be missing something easier. As is, we'll have to remember to test it again with v11 which I agree is not ideal!