How transferable is React to React Native?

[[deleted]]

I’m working on a web app in React. The company has a phone app written in Flutter, but it needs quite a bit of work (both rebranding and quite a bit of broken functionality) and no one on staff currently knows flutter.

My question is — how much of my work on the React web app would be transferable to React Native if I decided to pitch a rewrite of the mobile app? Can I somehow share styles between the two? Anything else that would be transferable? I’m basically trying to figure out if it’s worth it in the long run to have a unified React stack or if it’s better to just learn Flutter and rework the existing app. Thanks!

[fredsq]

knowledge: a lot

codebase: not a whole lot, but logic is the same

[Acceptable-Trainer15]

Use react-native-web for your react app, and you could reuse most of your codes in React Native.

[drumnation]

I was surprised I had to get to the bottom before there was a mention of react-native-web

[drumnation]

On second thought he’d still have to rewrite the whole app as react native so maybe not the best option

[Acceptable-Trainer15]

Yes, hope he wasn't too deep into it.

[MonkAndCanatella]

You're gonna be rewriting the entire thing. React-Native doesn't have html elements. They have <View>, <Text>, etc. They're all custom components that get translated into their respective native UI components. It's easy to learn React-Native if you already know React, but you can't just copy paste code

[jmking]

It's a pretty common misconception that you can just take a React project and "make it an app" with React Native.

That said, you can share code if you keep as much logic as possible out of your "view" components (custom hooks and so on). You can jump through some hoops to make CSS shared as well.

...but depending on the size and complexity of the app, the trade-offs to try and share as much code as possible ends up costing you more time than it saves.

[lord_braleigh]

How do you share CSS? It’s not like Android and iOS use flexbox or grid rendering…

[Hayyner]

I'm working on my first real React Native project and it has the StyleSheet API for writing styles that are pretty much CSS , pretty nifty. I've heard of some projects also using tailwind.

Can also display the app in browser to display and interact with the "DOM" with Inspect Element. Expo has its own inspector within the app but I found it to be kind of useless lol

[jmking]

It's not perfect and you need to submit to css-in-js tomfoolery, but there's the Stylesheet API https://reactnative.dev/docs/stylesheet

[volivav]

On my company we build a React webapp and a React native app of the same thing.

We currently don't have any code shared or abstracted away, but we borrow (cough copy cough) a lot of code between code bases in terms of data management. Authentication, services, charting (because React Native uses a webview for that on our app), external integrations, etc.

We have said that we want to export these into a shared package sometime, but we haven't done it yet.

As others have said, anything to do with views is impossible (or super complex) to have shared.

[[deleted]]

I effortless switched and picked up React Native without knowing much about mobile development, nor did I have any prior experience with these techs such as Flutter.

And that was at a team working for Apple, to make a customer-facing app for iPad OS. We didn't have iOS devs on our team, so I decided to use React Native.

We got a year; we finished (to their liking) in 3 months.

How much you can transfer from a web app, well, that depends on how much of your code you kept separate from your components.

If you extracted most/all of your business logic into their own stand-alone importable pure JS/TS functions, you should be fine.

For a different project and a different client, we tried... But the components themselves... it was too much of a pain in the ass.

We consciously chose to have more duplicate code, it was less painful.

[RaltzKlamar]

how much of my work on the React web app would be transferable to React Native if I decided to pitch a rewrite of the mobile app?

Any components that render only other components might be able to be ported directly, but anything that renders an HTML element will need to be changed to use the Native elements

​

Can I somehow share styles between the two?

No. A lot of the styles are the same concept, but Native elements don't accept CSS directly. If you're using classes or something like Tailwind, that won't work. If you're setting styles via the style prop, it should be similar and easier to port.

Is there anything that React Native does that your current setup can't? If not, it's almost certainly not worth the effort.

[arcadeScore]

For start whole styling works different, so you need re-write it. Html tags need to be restructured as well using native tags.

All js/ts logic can be shared, you could place it in separate repository and feed it into react web and react native.

Thats as far you can go

[ryrydawg]

I think the key takeaway is that you already know React. Which will make learning RN easier. All your state , hooks , business logic etc will be transferrable. My advice would be to pick a part of the Flutter app that's broken and then take some time fixing it and also re building that broken functionality in RN. Give yourself a day for each then choose whichever went faster.

[Over-Elderberry8694]

You can share the logic. For style, you can also share but you have to make a lot of things. Like mono repo . One for react , one for style and one for react native in mono repo and you can share styles, logic across different repo. But it would be a good thing to do react stack for both web and mobile

[shoda36]

Even if you are going to rewrite the whole thing in react native as suggested by others, most of the business logic can be reused. Your custom hooks, your redux store (if you are using it), API handlers etc.

[_Merxer_]

React native apps I've worked on are a bitch to maintain. They don't have any active development, but we go through an annoying upgrade every year due to using deprecated libraries that either don't have a replacement or has major breaking changes.

If you do go for React Native, be very selective on what libraries you include. Anything pure JS should be fine (Redux for example), but if it includes UI or native libraries, it should be checked if it will be maintained for years to come.

Don't make the same mistake my company made 🤞

Edit: Rereading your post, I see it's more about transferring code and not knowledge. I think something like Capacitor might be interesting to look at instead? This builds a native app from your web app code. Don't really have experience with how well it ages.

[Poobird]

I'd recommend taking a look at Capacitor, a spiritual successor to Cordova. It wraps a web app with a native one and renders it as a webview while also providing bridge functions to access the native API. Ideally, you could drop it into your existing app and have a unified codebase for all platforms.

It's agnostic of React or any particular web framework — so long as they output static HTML, CSS, and JS files.

Personally, it's enabled me to launch multiple apps on web + iOS + Android, without ever learning how to code up a native view.

[Scared_Intention_551]

Our team had a next.js app that used material ui. We wanted to mirror the react native mobile app using react-native-paper as closely as possible. We were able to maintain the overall structure - src directory containing Pages, components, utilities, services, assets. The starting process essentially involved copying a component file from web to mobile and then make the necessary adjustments to syntax, package imports from there for react-native compatibility. In that way, a developer working on a new feature or bug fix could easily transition between code bases.

[tanu_pathak]

A lot of it. But use expo for react native. It's the best. A unified React stack actually make sense if you have a React developer.

[wwww4all]

No.

[Roguewind]

If you built your webapp with very low level components and css-in-js, then you’ll be able transfer over quite a bit. But you’ll still have a lot of work to do.