Redwood: Adding Sides: React Native support

[vilvaathibanpb]

Adding React Native as a side to redwood and let people create hybrid apps.

Attack plan:

1. Adding --mobile flag with create-redwood-app creates a mobile folder with react-native android and ios setups.
2. This also requires the user to have Android Studio, XCode and Cocopods setup already in their machines
3. yarn redwood generate screen screenName would create a new screen using wix/react-native-navigation
4. The mobile folder created will already support SVGs & theme-UI (Planning to extend to Maps, Images, Dimensions, Shadows, support for allowed styling, background image, Animations and few others in the next phase)
5. Storybook integration to RN

[skv-headless]

1. what do you think about expo instead?
2. why not react-navigation? Still seems more popular

[vilvaathibanpb]

@skv-headless ,

1. Expo is easy to kick start but to get the builds to app store, one needs to pay. And to use few libs which needs some modification on native code, its gonna be a pain
2. I am open with react-navigation as well, however I am not sure if its as stable as wix/react-native-navigation.

[peterp]

@skv-headless react native navigation was originally a pure JS based navigation library. They recently changed to native.

I haven't really evaluated react-native-navigation with their new API, but have enjoyed using Wix in the past and found it stable, well documented, and actively maintained.

[petrbela]

Expo is easy to kick start but to get the builds to app store, one needs to pay.

This is a bit misleading. Expo apps are still React Native apps, so you can build and publish them to the app store yourself for free. You only need to pay if you want priority builds in their cloud. (Though specific rules could change in the future, I don't think they'll ever prevent you from publishing your apps for free.)

Expo also works on the web (really it's just a glorified react-native-web with some improved compatibility) and has Next.js integration so, in theory, one could write a single redwoodjs app that would run on all three platforms from the get-go. Though I understand that defaulting redwood with Expo might pose some ownership challenges, I think it would make it easier for users to get started while always having the option to eject to a regular RN app.

[Albert-Gao]

Expo is good, and in terms of case you want to gain control over the native side, that is a problem for native RN as well, you have to manage it by yourselves. Maintaining those native dependencies does not only mean manage them, you have to manage the whole RN version upgrade path. If you use expo managed flow, you do not need to worry about it.

But, put that aside, I think if redwood wants to integrate RN, there are several ways:

• use Expo managed workflow:

  • pros:
    
    
    
    • pretty much everything works out of the box
    
    
    • no ios and android folders for the user, pure js
    
    
    • no maintenance for the whole flow, (for RN, upgrading work is a big thing)
    
    
  • cons:
    
    
    
    • always behind RN latest version since the maintenance work is huge (for native dependencies)
    
    
    • and it has other limitations like install native dep is impossible.
    
    
    • bigger bundle size since expo integrates a lot of native modules even though you do not need them
    
    

• use Expo bare workflow:

  • pros:
    
    
    
    • you gain full control
    
    
    • built-in support for react-native-web as well
    
    
    • it is just a plain RN + RNW support
    
    
    • every time expo updates their version, we just upgrade the template
    
    
  • cons:
    
    
    
    • now you see the ios and android folder, which contains the native project
    
    
    • the maintenance burden is on the user now (or redwood?)
    
    

• Redwood integration: use plain RN + own webpack config for RNW with

But it is never that easy, The hard parts are:

1. You have to change the primitive, it can't be the web anymore, has to be RN first, for example, instead of depending on <div>, <span>, <button>. you have to depends on <View>, <Text>, < Pressable >.
2. The style solution has to be inline style because RN 1st, otherwise, you have to reinvent the wheel, and the performance won't be great (for example, styled-components for RN, it has other problems like the styling engine is different, RN uses yoga while the browser has its own engine and follow web standard)...
3. forget about fancy things like grid, media-query, make-you-feel-smart-css-properties because RN 1st

The above problems can be solved in a way that redwood start to ship its own primitive component:
for example, <Box>, <Text>, <Stack>, so it will abstract the RN's <View>, <Text> from the user

For example, in my codebase, I use my own <Box> component, and it is fully type-checked for the theme I generated, and the related types will be generated as well, no styles generated on the fly for performance reason, they are all predefined values. Which means, even for the web version, the same property you use, will generate only one class, like tailwindcss.

It does not do anything else, its purpose is to fill the gap of theme-based primitive components, all your other components are based on these, after this user-land abstraction, we can start talking about cross-platform solution.

Just my 2 cents though. Let's make it happen :) Would love to contribute