RJS-2888: Fixing React scheduler's call to RN CallInvoker
's invokeAsync
and upgrading our RNTA test app to React Native v0.75.1
#6851
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What, How & Why?
This closes #6845 and #6846 by updating RN specific scheduler to use a backwards compatible call signature for
CallInvoker
'sinvokeAsync
.A bit more context on the proposed changes
React Native's CallInvoker API changed with facebook/react-native#43375, such that the
func
callback argument now takes ajsi::Runtime
. This was first released as[email protected]
.Care was made in that PR to provide signatures for backward compatibility, but these were only added for overload that doesn't take a
SchedulerPriority
as first argument (which we depend on). As I see it, we have a few ways forward:jsi::Runtime
argument.SchedulerPriority
(without ajsi::Runtime
in thefunc
).Option 1 will leave
realm
broken for0.75.0
and0.75.1
forever and depends on the grace and a hotfix from the React Native team to be immediately effective. Option 2 will make the coming release ofrealm
backwards incompatible withreact-native
prior to0.75.0
which would be very unfortunate and could potentially require a major version bump on our side. I believe our best option now is 3, as that will alleviate the immediate issue fast and good compatibility, although we'll be providing less context when calling into the call invoker.☑️ ToDos
Compatibility
label is updated or copied from previous entryCOMPATIBILITY.md
package.json
s (if updating internal packages)Breaking
label has been applied or is not necessary@realm/devdocs
if documentation changes are needed