Open Lelelo1 opened 3 years ago
I rather use a high level approach and go from there. There should be matching functionality in rns and rn. But you know this realm better than me. For instance instantiation should be practically the same I guess.
Some weird way of doing it just to see something would be to create a react native android ui element and replace with a nativescript android
property (which is the native instance in nativescript)
You may need an additional loader to handle the result of these loaders.
The react-native
package is problematic to import JS from for a few reasons:
.js
files are written in Flow, so you'd need a Webpack loader to pre-process them.All of these problems have been solved, however, by react-native-web. For one thing, they use a Babel preset metro-react-native-babel-preset to polyfill some modern JS functionality like optional chaining. For another thing, they use a Babel plugin, babel-plugin-react-native-web, to rewrite imports from react-native
to react-native-web/dist/exports/<module>
, where they've re-implemented the same module themselves for Web. They then do some module-aliasing to alias react-native
to react-native-web
. You can see how they put it all together in a Webpack config like this.
Evan Bacon (on the Expo team) has also managed to build React Native Android/iOS using Webpack rather than Metro, so that would be interesting to study, too (as it removes React Native Web from the equation).
I rather use a high level approach and go from there.
To be clear, porting React Native to NativeScript from the top down would be an enormous project. It is a project on exactly the same scale as React Native Web, which took years to build and required serious special expertise. Even just to get View and Text components working, you'd need to implement the Bridge, StyleSheet, Pressable, Accessibility, UIManager, logging, error handling, event bubbling, perhaps codegen, and the list goes on. I think it would be a never-ending rabbit hole and we might never get to see the component working.
I think porting it from the bottom-up, just taking the bits we're interested in (e.g. starting with View and Text), would be more realistic as a spare-time project with few contributors. It's certainly the faster way to get to a proof-of-concept stage. To do that, one would have to look at how React Native's View is implemented in JS, and try to implement something like NativeScript's FlexboxLayout, but using React Native Obj-C/Java View component as the native view for it.
That said, it's probably worth looking at how React Native Web implemented View and Text, and looking at the project's earliest commits, to see if a top-down approach, focusing on only one or two components, could be viable. I don't totally understand what would be involved yet.
EDIT:
Hah – it looks like the earliest commits of React Native Web didn't even include react-native
as a dependency! They just implemented all the same APIs as React Native did. This is exactly what I did to try to support equivalent View and Text components in React NativeScript v0, two years ago. Unfortunately I was limited by NativeScript itself – it doesn't support position: "absolute"
in FlexboxLayout, and NativeScript's TextView/TextField components are very limited, so it was impossible to make truly equivalent views just using NativeScript primitives.
I think that (the bottom-up approach) would thus be far simpler and quicker to do, as well as far more realistic.
I've successfully made a React Native plugin for NativeScript now!
https://github.com/nativescript-community/react-native-in-nativescript/tree/master/apps/demo-react
It fully supports both Android and iOS, and includes typings for both, too. No need to change your App_Resources/Android/app.gradle
– installing the plugin handles everything!
This if the first problem encountered when using anything in the react-native npm directly:
I guess i'ts related to flow and webpack @shirakaba