realm
new architecture adoption
#95
kraenhansen
started this conversation in
Libraries
Replies: 1 comment
-
Last week we released the first alpha release of our re-written SDK: https://github.com/realm/realm-js/releases/tag/v12.0.0-alpha.0 |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
TL;DR
realm@11
(18th of October 2022) with support for JSC and Hermes through JSI. See our blogpost for details.I hope this discussion will help shed some light on the ongoing efforts of the Realm JS team into supporting the new RN architecture.
Historical context
Our JSI adoption & Hermes support
Our endeavors into the new architecture started as we implemented a JSI "backend" for our JS engine abstraction. We aimed to use this to replace our existing JSC "backend", as a JSC runtime was already available for JSI. This shipped the first time as
v10.20.0-alpha.0
, initially supporting iOS only, on the 1st of September 2021 and support for Android was introduced withv10.20.0-alpha.1
on the 22nd of September 2021. We've fixed some bugs since, but at large our support for JSI hasn't been changing that much since then.Most notably, we've seen performance regressions:
We decided to drop support for the legacy chrome debugging mode, for a couple of reasons:
This has the unfortunate side-effect that users that haven't yet adopted Hermes and are not on a Mac, have no known way of debugging their apps if they're using Realm JS v11 (or later). Unfortunately this also includes dropping support for tools like the very popular react-native-debugger. There's no doubt we're betting on Flipper becoming the de-facto debugger for React Native developers.
Our future
We're currently in progress with a complete rewrite of our SDK (to be released as v12 - when it's ready) and expect to adopt TurboModules in the process and some codegen in the process. We expect very few breaking changes to our external API, but a major overhaul of our internals. Most notably, we're now exposing a TypeScript binding for our internal database core library, which we expect will result in fewer bugs, less code to maintain and an increase in developer productivity on our team.
Since we're already generating a binding exposing our native C++ code via TypeScript, we expect very little leverage from the RN codegen tooling. We'll most likely expose a single method calling into C++ and returning an object with a lot of free functions that we bind into classes from JS code generated by our own binding generator.
I realize now this post got a bit longer than I expected: I hope this will inspire other maintainers and provide a bit of context for users of RN and our library. Please feel free to ask any questions for us regarding our adoption of the new architecture, here or more informally on the #realm channel on the "React Native Contributors" discord.
Beta Was this translation helpful? Give feedback.
All reactions