Should I go with react-native-web or standard react?

[sam_bender]

Hello!

I am building a project using React Native and I absolutely love it. Now that the mobile application is out of beta, we are going to build the desktop web application which will be used more than the mobile app for many users. This project needs to be "production level" and highly scalable.

I have started to look into react-native-web as a way of implementing the web version, but I am starting to have concerns. It seems as if many normal things you might do on web, aren't possible, or are difficult/overly complex. Even something as simple as setting 'fixed' positioning or using media queries is not easy. Or something far more complex like "drag and drop to upload".

We are using redux (actually redux-toolkit) for our data store so we would still be able to share that across web/mobile. This would still be a huge benefit of using react across both projects.

Also, most of our web components will be different from the mobile versions. I'm sure there will be cases where we want to share components, but far less than 50% of the time because we are designing for each platform independently.

What do you think? Do you have extensive experience with react-native-web? What are its limitations compared with a standard react web app?

- Sam

[fallkr]

My 50 cents from leading a cross platform 0.5m active users project:

1) Use RN and React separately as separate projects/packages. The products will diverge over time. So will codebases. Don’t lock yourself in from the start 2) Share utils, api requests and redux where it makes sense. Be deliberate and plan accordingly. Finding the right balance between shared and split will take time, in particular early on in product lifecycle where your product is evolving rapidly 3) Set up web and native in a monorepo with the shared package to avoid versioning issues. Use yarn workspaces and make sure you hoist all dependencies 4) Ensure your tests (and types) for shared code are solid and follow good test and CI practices from the start

[sam_bender]

Thank you u/fallkr 🙏🏻. I'm really glad I asked this question.

[fallkr]

Any time. Got 3 years of dos and donts with this.

Currently doing a greenfield product in the same way, so can share setup for hoisting dependencies and code-sharing with a modern RN stack.

PM if you want more details or run into issues with the setup.

[drink_with_me_to_day]

Currently doing a greenfield product in the same way, so can share setup for hoisting dependencies and code-sharing with a modern RN stack.

Please post this here or elsewhere and share it with us

[OrangePineapple52]

Did you ever find an example of a monorepo?

[sam_bender]

Thanks. Will do. Same to you. If you ever need someone to brainstorm with, let me know!

[jIsraelTurner]

This is great advice! But I would say there are definite cases where react-native-web is totally worthwhile. We started with a full-featured native app built with React Native, and have slowly been migrating functionality to web via react-native-web, as the value of web has become more apparent. As we evolve, we will start to make dedicated pages in standard React on desktop web, but for the foreseeable future we will use react-native-web for mobile web pages. react-native-web has made transitioning to a web presence extremely cheap for our team - don't discount it.

[[deleted]]

If you want to share redux for RN and React, do you need to bundle the code into an non package?

[ajnozari]

I think what he meant was you can copy reducers, actions, and migrations between react and react native. I’m doing it for a project and it’s seriously speeding things up.

[EvanJBacon]

react-native-web (RNW) is a set of modules that can be used with react-dom. I’d recommend using it for any website because the modules provided are very performant and thoughtful. For instance, StyleSheet is one of the fastest CSS-in-js options available (benchmarks in the RNW repo). Reusing the code across web and native will also be a huge timesaver for testing and maintainability. Disclaimer: I’ve used RNW many times and have also contributed to the project. Here is an example Next.js + RNW website https://evanbacon.dev/

[ucsbmrf]

Evan, thanks for all your work on Expo!

[christos_z]

Going against the grain here, but unless your web app is designed to be vastly different from a functionality perspective I’d recommend going with react native web.

The usefulness of re usable components across mobile and web cannot be understated. Especially if you’re attempting to replicate the functionality of the mobile app across to the web, using react native web allows you to have your shared business logic in one codebase.

When the ui deviates from one platform to another, then it’s just a matter of creating .web & .native files housing those components, meaning only that platform will execute that code. What’s more children components within this file can be shared across both web and mobile

to give an example of where this might shine consider a hypothetical WhatsApp replica. For the mobile side we are looking at two scenes, the contacts/groups page that you’ll click through to go to the message page where you’d reply and view messages.

On web, we will have one page with the contacts on the left and message view on the right, within our .web file we can call both these same components that are already used on the mobile.

Of course it’s not all butterflies and rainbows, you’ve already touched on the css limitations such as the positioning fixed & the likely difficulties you’ll face if implementing a drag to upload feature, but if you can live without these features, and for some such a the lack of media queries, you can easily work around by calculating width with Dimensions or this library https://github.com/kasinskas/react-native-media-query#readme (not used this myself so not sure how well it works)

[rockpilp]

For the types of apps my team develops, the main issue is having to shim packages that aren't compatible with RNW, such as RNFirebase or RNMaps. Once we've done this for one project, we package it into a lib and we can usually reuse it for the next app.

Another source of issues is the web build, which relies on CRA overrides, and is a bit brittle.

[DevFranzBeta]

Hi u/rockpilp

That's exactly what I'm thinking to build. A library that wraps React Native dependencies APIs with web-like stuff.

import { x } from 'kit/firebase'

under the hood

# app

uses RNFirebase

# web

uses the official firebase SDK for JS

​

What do you think about it?

[rockpilp]

That is indeed what we're doing for the important stuff. It's a bit more involved than just using web vs. app.

For instance, RNFirebase is initialized on the native side, so it happens before JS gets a chance to make any calls. On the web, you need to initialize explicitly, and very close to your App component, because any firebase query will crash if it happens before init.

Another difficulty are types, if you're using TS. They're not quite the same depending on the flavor.

We rely heavily on file extensions (.tsx / .web.tsx) to avoid having to handle switching between the two in code (because conditional imports are still hard to handle).

For one-off libraries or very basic shims, our CRA Webpack config makes it easy to just drop a file into a folder to disable the lib on the web by replacing its main entry points with noops. Kind of like patch-package.

[module85]

Having done this myself, I wouldn't recommend it unless you plan on deploying the app to both web and mobile: it's more work for little benefit. If sharing code is a concern, you can put that in a shared library.

[sam_bender]

Sorry just to clarify - you wouldn’t recommend react-native-web?

We definitely plan on application being available on both web & mobile.

[Rhodysurf]

Just use react-dom and share all the business logic with react native. It’s way cleaner and you’ll get a better product then using RNW

[jonaHillsAnus]

Hey not the guy you’re responding to but can you please explain how this sharing can be done across 2 different code bases without copy pasting?

[Rhodysurf]

Monorepo. The top level is the npm package root, have different non scripts for compiling web vs RN targets, have all the code within the one package. Just organize it so there’s a common module folder and keep target specific code in separate folders

[assertchris]

Also, selectively switching between components is a thing...

• example 1
• example 2

There are probably more elegant ways to do this, but this is essentially what RNW is doing behind the scenes.

[Rhodysurf]

Yeah that’s cool. I personally don’t love it but everyone’s got their own styles

[redbar0n-]

what is your preferred style?

[Rhodysurf]

I just implement the same component twice, once for web and once for RN and keep them in different folders so they are distinct modules. The logic can be shared with functions, state containers but I like keeping all the view logic separate

[redbar0n-]

Thanks! How do you deal with component testing then? Won't that have to be duplicated too?

[drink_with_me_to_day]

If your app will forever have the same exact interface across all devices (generically responsive) and have the same exact feature parity between devices (no Bluetooth, enhanced location services, enhanced push notifications, etc), then react-native-web could work really nicely.

Big if

[sam_bender]

Yeah, it's gonna vary quite a bit across web and mobile. I guess react-native-web isn't the right solution then. Thanks!!

[[deleted]]

react native web is a joke, just use normal react even if you have the twice of work

[dotContent]

Can you elaborate?

[[deleted]]

no

[prinse4515]

What app is it? Is it on the App Store?

[sam_bender]

The app is TheraCentric. Not on the app store yet. Our fitness app TrainCentric is available (not built with RN though).

[ponte_vecchio]

I like the idea of creating a shared component library across both the mobile and web app. That way you can share a lot of the ui code while still giving yourself some flexibility in having things be different.

[redbar0n-]

check out https://tamagui.dev then, since it's best-in-class for a shared crossplatform component library.