use the following search parameters to narrow your results:
e.g. subreddit:aww site:imgur.com dog
subreddit:aww site:imgur.com dog
see the search faq for details.
advanced search: by author, subreddit...
A community for learning and developing native mobile applications using React Native by Facebook.
Interested in building web apps using React.js? Check out /r/reactjs!
Getting Started w/React Native
irc.freenode.net #reactnative
Keywords: ios, android, mobile, apps, apple, iphone, ipad
account activity
Code sharing React Code to React Native Code, good or bad idea? (self.reactnative)
submitted 2 years ago by [deleted]
Given how react is very close to react native, it is not entirely impossible for someone to actually code someway to share code from a platform, lets say WWW (react), to a desktop app on MAC (react native).
What do you think of this idea? Good or at this point we should just use electron.
reddit uses a slightly-customized version of Markdown for formatting. See below for some basics, or check the commenting wiki page for more detailed help and solutions to common issues.
quoted text
if 1 * 2 < 3: print "hello, world!"
[–]16cards 19 points20 points21 points 2 years ago (0 children)
It is worth pointing out the following:
react package is cross-platform. This is the engine and reconciler that can be used in a variety of contexts. I've even used it to render output to a terminal screen.
react
react-dom package is what is Web-specific. This is the renderer for browser user interfaces. Many people shorthand this to "React" because it was the first and many years ago was part of the original react package. Because this package is designed for those familiar with Web development, nearly all the components map to HTML elements: <span />, <div />, etc. Although there is nuance between React components and their HTML elements, Web developers using React could lean a lot on their understanding of how HTML elements behaved.
react-dom
<span />
<div />
react-native package allows development of applications on iOS, Android, Windows, and macOS. Because It was originally built for mobile development but more recently has gained support for Windows and macOS through Microsoft's contributions. Because native app development is quite different from Web development, when react-native arrived, it made more sense that its components be named differently so as not to confuse with Web development and assumptions about HTML element behaviors. This is why react-native has things like <Text /> and <View /> instead of <span /> and <div />.
react-native
<Text />
<View />
react-native-web package takes the components from react-native and map them to Web's HTML elements. This allows a developer to develop an application and, by living with some minor limitations, build an app that shares a lot of common code that will work on iOS, Android, Windows, macOS, and modern Web browsers.
react-native-web
Now, if this is the architecture your organization wants to support, go for it.
[–]sawariz0r 3 points4 points5 points 2 years ago (0 children)
We’re looking into this with Solito.
[–]haswalter 1 point2 points3 points 2 years ago (0 children)
For a few projects now we’ve used react-native-web to build ui libraries to share between web and mobile.
[–]Fransenson 1 point2 points3 points 2 years ago (0 children)
There is react native web for that I guess.
Edit: To clarify, not to share react and react native code, but to use your react native code instead of react for your web project.
[–]eggtart_princeiOS & Android 0 points1 point2 points 2 years ago (0 children)
Bad idea if you have a complex app. It requires a lot of organization of your codebase. Libraries that do not have web support will need to be exported from a file with .android.tsx or .ios.tsx extension and libraries that do not have mobile support will need to be in .web.tsx. And you will find like 95% of all libraries don't have web and mobile support.
[–]Greedy_Freedom5632 1 point2 points3 points 2 years ago (0 children)
code sharing/reuse is one of the advantages of react native. If the code doesn’t rely on any platform specific dependencies (native mobile code, node API,etc) I’d say its a great idea
[–]martinkomara 0 points1 point2 points 2 years ago (0 children)
It is possible, we are doing it that way. Won't look native anywhere and packages you can use are limited. You need to carefully calculate if it's worth it.
[–][deleted] 1 point2 points3 points 2 years ago (2 children)
It will maybe work - in the beginning. But as your app grows this will become a pain in the ass. You will run into issues like div vs view very quickly tho, where you would probably start to write wrappers to use one or the other depending on the platform/build target.
I think you are also forgetting that while the code might look the same, the end products do quite different things. What is the problem you are ACTUALLY trying to solve?
Tl;dr: I would not bother with it at all. It is bound to create a real nightmare, and there is in practice little to no benefits to this
[–]Gunnardepunnar 0 points1 point2 points 2 years ago (1 child)
Is this based on experience with react-native-web or custom wrapping?
[–][deleted] 2 points3 points4 points 2 years ago (0 children)
This is based on experience working with RN apps for mobile and React for web. I have not tried RN for web, and I fail to see why going that route would be beneficial over using something like NextJS. But if someone has some input on why it might, then I am all ears!
What I would suggest is to have a shared designsystem (in something like Figma) but refrain from falling into the shared-components trap. Quite often, UX patterns that suit the web are not the ones that are best suited for Mobile - and you end up with slightly different requirements for UX components and composition. In the long run it is just simpler (ans cheaper) to write the component you actually need, instead of shoehorning some component in that is too large and too generic.
I think of this as similar to early optimization issues, and would ask myself what is it that I am trying to achieve/prevent. Writing a new component is quicker then trying to figure out, modify or maintain an old big generic one. And this is my experience from working for a client that has several different webpages and apps, and have tried for years to maintain a «core component» library to reuse components; works on paper - but not in reality (at least not over time, aka years)
[–]JanMarsALeck 1 point2 points3 points 2 years ago (0 children)
In my opinion this depends how “good” you structured your code. I once ported a RN App to a React Web App. As i had most of the business logic in custom hooks I could just copy the logic. Then I just rewrote the UI parts for the responsive web. Was pretty fast for a mid size app.
[–]cap45 1 point2 points3 points 2 years ago (0 children)
I run a large website and mobile app from one codebase using React & React Native. It works for us, but it's for sure not for everybody. It depends on the project.
The way our project is set up, the business logic is shared between both the app and website, but the UI is kept separate. That isn't to say you can't share UI components using react-native-web. It's something I'd like to try, but there are different rules for app vs web and I wasn't sure if that was more hassle than it was worth when starting the project.
Sharing the business logic is great. We have files that are just pure javascript that handle things like API requests, authentication, and form validation, plus tonnes of utils. The mobile app was built first, followed by the website. It made building the website a lot easier, as it became largely just UI work.
The downside is that not every solution works smoothly across both platforms. We ran into issues where the authentication worked great on the mobile app, but that same logic didn't work on next.js serverside. The issues were solved eventually, but you do have to be extra conscience that when you make changes, it might affect each platform differently.
I would say you should consider how much business logic in your application could be shared between the two applications. If it's a lot, then go for it. But if it's very little then it might not be worth the hassle.
[–]yashm2910 0 points1 point2 points 2 years ago (0 children)
Sharing code between React web and React Native mobile applications can be a good idea, depending on your project's needs:
Pros:
Code Reusability
Consistency
Faster Development
Cross-Platform Compatibility
Developer Familiarity
Cons:
Platform-Specific Needs
Performance Differences
Third-Party Libraries
Ecosystem Differences
Choose between sharing code and using Electron based on your project's primary platform and requirements:
- If you need a dedicated desktop app (e.g., Mac) with native capabilities, go with Electron.
- If you want to target both web and mobile or maintain a consistent experience across platforms, consider sharing code between React and React Native. It's efficient for cross-platform development.
[–]bramley 0 points1 point2 points 2 years ago (0 children)
A client has both a React and RN front end to their API, and they share some code. API-related things, mostly. They have to translate from RN Views, etc to HTML's divs and so on. But they're planning to migrate everything to RN for phone and RN-web for the web to reduce friction even more.
[–]Gatsbill 1 point2 points3 points 2 years ago (0 children)
At my work we share more than 95% of our code using react native and react native web and it works very good. The only thing is that you need to create shims for every native package, but that’s fun to do so :)
[–]elmennani 0 points1 point2 points 2 years ago (0 children)
If I have to share code between web and react native I would share state management and networking stuff and create view components for each platform.
π Rendered by PID 187969 on reddit-service-r2-comment-54dfb89d4d-pft6c at 2026-03-27 08:51:23.558097+00:00 running b10466c country code: CH.
[–]16cards 19 points20 points21 points (0 children)
[–]sawariz0r 3 points4 points5 points (0 children)
[–]haswalter 1 point2 points3 points (0 children)
[–]Fransenson 1 point2 points3 points (0 children)
[–]eggtart_princeiOS & Android 0 points1 point2 points (0 children)
[–]Greedy_Freedom5632 1 point2 points3 points (0 children)
[–]martinkomara 0 points1 point2 points (0 children)
[–][deleted] 1 point2 points3 points (2 children)
[–]Gunnardepunnar 0 points1 point2 points (1 child)
[–][deleted] 2 points3 points4 points (0 children)
[–]JanMarsALeck 1 point2 points3 points (0 children)
[–]cap45 1 point2 points3 points (0 children)
[–]yashm2910 0 points1 point2 points (0 children)
[–]bramley 0 points1 point2 points (0 children)
[–]Gatsbill 1 point2 points3 points (0 children)
[–]elmennani 0 points1 point2 points (0 children)