-
Notifications
You must be signed in to change notification settings - Fork 577
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
RJS-2815: React Native bridgeless support (take 2) #6737
Conversation
e448000
to
1b09689
Compare
1b09689
to
a7d26ea
Compare
@@ -139,7 +139,7 @@ async function run(spawnLogcat) { | |||
if (PLATFORM === "android") { | |||
// Start the log cat (skipping any initial pid from an old run) | |||
if (spawnLogcat) { | |||
logcat.start("com.realmreactnativetests", true).catch(console.error); | |||
logcat.start("com.microsoft.reacttestapp", true).catch(console.error); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Technically no longer needed, but it does fix an issue of spawning logcat when running locally.
a7d26ea
to
d774f35
Compare
@@ -1,45 +0,0 @@ | |||
/* DO NOT EDIT THIS FILE - it is machine generated */ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This file is not needed as no code is referring to these symbols externally.
|
||
#include <ReactCommon/CallInvoker.h> | ||
|
||
namespace realm::js::flush_ui_workaround { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As part of #6718 I did a refactor of the "flush UI workaround" which I decided to keep in this PR, since I felt it was a nice increase in the separation of concerns.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My comments are not blocking but merely suggestions and questions to clarify a few things (for me)
packages/realm/RealmJS.podspec
Outdated
s.source_files = 'binding/jsi/*.cpp', | ||
'binding/apple/*.mm' | ||
'binding/apple/platform.mm', |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is the any reason for not using all .mm
files?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nope. I don't remember why I changed this. I've updated this to be 'binding/apple/*.mm'
again.
{ | ||
__android_log_print(ANDROID_LOG_VERBOSE, "JSRealm", "setDefaultRealmFileDirectory"); | ||
|
||
__android_log_print(ANDROID_LOG_VERBOSE, "Realm", "install"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we use Core's logger instead?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Core isn't necessarily loaded into memory at the point of calling code in this file, so I'd rather - not to keep things simple 🙂
// Calling loadLibrary multiple times will be ignored | ||
// We do it here instead of statically to allow the app load faster if Realm isn't accessed. | ||
// Effectively emulating the behaviour of TurboModules. | ||
SoLoader.loadLibrary("realm"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we wrap it in a try
/catch
to provide a better error mesage?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I imagine the SoLoader will provide sufficient information - we can add to this if we see common patterns emerge, but right now I don't know what I would write to make it more actionable for developers 🤔 It used to be the case that people forgot to react-native link
but that's a thing of the past.
realm::js::flush_ui_workaround::reset_js_call_invoker(); | ||
__android_log_print(ANDROID_LOG_VERBOSE, "Realm", "Invalidating caches"); | ||
#if DEBUG | ||
realm_jsi_close_sync_sessions(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please include the comments as in RealmReactModule.m
50f526b
to
acb518d
Compare
I have still not being able to migrate my project to new architecture but super happy to see this ongoing. Just writing to say thank you @kraenhansen ! |
@ferrannp Honestly, a comment like that means more to us than you might know 🙂 Thank you! |
What, How & Why?
This closes #6653 by introducing a new implementations of the way we register our native module on both iOS and Android. I suggest relying on the legacy
NativeModules
compatibility layer for now, since the current state of pure C++ TurboModules are largely undocumented and experimental: We could revisit this decision in the future by introducing an alternative implementation, conditional on the new architecture being enabled in the app.This approach aligns with others vendors having exposing their native C++ / Rust based native libraries through JSI.
This still injects the binding into the JS global, from where the "JS wrapper" of our native module is able to read and delete it again. With these changes, we're now deferring the injection of this (and the loading of our .so on Android) until the very last moment it's needed, essentially getting the benefits of deferred loading that TurboModules bring:
realm-js/packages/realm/binding/android/src/main/java/io/realm/react/RealmReactModule.java
Lines 63 to 66 in d774f35
Since we're implementing and injecting our binding onto the a global using JSI, we're not relying on the legacy bridge compatibility layer for every call from JS into C++ and I therefore expect this to be as fast as a TurboModule would be.
I did attempt to inject the "JS call invoker" for the "UI flush workaround" only if bridgeless is disabled, as facebook/react-native#43396 fixed this for bridgeless and we don't want to pay the cost if it isn't needed, but it didn't work. We could still experiment with using the JSI Runtime::drainMicrotasks() API if available.
☑️ 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