Usage with React Native (+ Web)

[nandorojo]

I just read the breakdown of Remix vs. Next.js, and wow, am I intrigued.

I've spent the last year/two building bindings between React Native and Next.js so that we can run the same code on both.

I have a number of popular libraries dedicated to this, and I gave a talk about it at Next.js Conf.

Naturally, I'm now wondering if something similar is possible with Remix. I understand Remix leans in heavily to the browser, which is awesome. I wonder if it would be possible to add .native.tsx files (even in userland) in order to share screens and components between Native and Remix.

Overall, it would be useful to have someone chime in and say if they think this is a possible future worth pursuing or not. It seems like the key differences would be useLoaderData, Form, and navigation. Not sure if I'm missing anything else there.

---

Update see this repo and this comment by @tyrauber.

[slorber]

I'm sending this in my React newsletter right now ;)
https://horus.dev/blog/react-native-web-remix-setup

I wonder if it would be possible to add .native.tsx files (even in userland) in order to share screens and components between Native and Remix.

I don't understand what you mean here. Why would you want Remix to read/understand the .native.tsx extension, considering Remix is for the web and not meant to run React-Native code that only aims native apps?

IMHO Remix should rather support/resolve .web.tsx extension, so that we can "override" native screens with a web-only implementation

Overall, it would be useful to have someone chime in and say if they think this is a possible future worth pursuing or not. It seems like the key differences would be useLoaderData, Form, and navigation. Not sure if I'm missing anything else there.

I don't understand that either 😅

[nandorojo]

IMHO Remix should rather support/resolve .web.tsx extension, so that we can "override" native screens with a web-only implementation

This is functionally the same as what I said about .native files. I'm just wondering if we can do per-platform files that are compatible with Remix/native. I want guidance on the best practice to do it.

Why would you want Remix to read/understand the .native.tsx extension

I don't. The .native files would be used on Native. What I'm saying there is, I wonder if we can add a .native.tsx file inside of the Remix library for every function/component that uses web-only code.

I don't understand that either 😅

useLoaderData and Form are Remix-specific imports. They include web-only code. So I'm wondering, how would these work on Native? Similarly, Remix navigation seems to do web-only routing. So I'm wondering, how would we achieve parity on native? And then I just asked if there are any other Remix-specific imports/concepts that wouldn't work on native out of the box that I forgot to mention.

[blackbing]

Interesting! Then we can separate client and server code basically. I hope it will happen.

[tyrauber]

@nandorojo, I am interested in this as well. I am very much a believer in one stack, many platforms. I absolutely love Expo for mobile application development, but need more for web application development - a database, api, caching, metatags, server side rendering. After reading through the Remix.run tutorials, I am excited for the potential of using Remix and Expo together.

My weekend project was to figure out that integration - remix-expo demonstrates basic monorepo integration of Remix and Expo.

Primary Challenge: Module Aliasing

The main challenge in getting Remix and Expo to play nicely is module aliasing - specifically aliasing react-native and react-native-web. Unfortunately, the speed and performance of Remix is in large part due to the simplicity of it's esbuild pipeline, but without Babel or Webpack the only options for module aliasing is through tsconfig paths. Further, Remix itself limits how your can import and bundle modules (presumably to help control bundle size and speed).

Solution: PNPM

The solution is to use PNPM package manager. PNPM allows you to alias modules at the package level, negating the need for other react-native methods of aliasing. As discovered and documented this in react-native-web-remix-setup. Thanks Horus Lugo!

Then it's just a matter of getting Expo to work with Monorepos. As Cedric van Putten, the Expo Monorepo expert detailed here, "That's not an issue related to pnpm, or Expo. It's just how Metro explains it can't find packages. I got it working with the --shamefully-hoist flag, and going over the steps in Working with Monorepos, in case it helps. byCedric/eas-monorepo-example#19

In regards to the react-native-web alias, I have found it is actually easier to write components using the react-native-web components and module aliasing back to react-native in expo using a babel alias. It is far harder to alias in remix than in expo. Hopefully, someone at Remix figures out a elegant way to allow for module aliasing.

Other Considerations:

There are a bunch of other things to figure out to make this a production ready stack.

• Where to store shared components
  I am currently storing shared components in packages/components, but neither remix doesn't watch packages. This is probably a tsconfig setting, but it would be really helpful for development to refresh in both expo and remix on changes.

• Routing
  React Navigation is the suggestion navigation for Mobile Applications. React Router is the suggesting navigation library for Web Development. We will need to figure out a single approach to writing routes, that can drive both react-nativation and react-router. I am really excited about this one.

• Templating
  It would be great to write templates in ReactNative Web, but a lot of the awesome Remix benefits come from the use of raw HTML -specifically form elements. It would be interesting to write a Form component that renders standard form elements in HTML for web, but react-native "forms" for mobile. Perhaps, a library already exists or this is more straightforward that I think, but it needs exploration.

• ErrorBoundaries
  It would be really awesome if we could make Expo utilizing Remix's Error Boundaries. It would allow for one consolidating error handling architecture.

Anyway, it's early days, but this is all very promising. If anyone wants to collaborate on this, hit me up on twitter, @tyrauber.

Special thanks to @HorusGoul and @byCedric for the heavy lifting.

[MiguelNiblock]

Are you able to use expo's unimodules inside remix? I have the impression that expo web is highly coupled with webpack/babel, and remix's esbundle restriction makes bundling less customizable. If I were pursuing this, I would use vanilla react-native instead of expo, so as to have a cleaner starting slate, and then gradually see how feasible it is to integrate other modules, making sure they work with both remix and expo mobile.
For example, how would you integrate component libraries in react-native which work on web (native-base, react-native-elements, react-native-paper), and expo-unimodules? These things require babel because they have native code for react-native, as well as web code.
Remix is more similar in architecture to nextjs, than to regular expo's react-native-web, and expo provides their nextjs adapter for that. So I would reason for expo to work well with remix, a similar adapter or other customization solution might be required. Ditching expo in favor of vanilla react-native would reduce the scope of the problem.

[MiguelNiblock]

For navigation, I've thought a few potential solutions:

1. It would be great if react-navigation ssr https://reactnavigation.org/docs/server-rendering/ could be used inside remix, so in the server config file, you could simply use react-navigation's <ServerContainer /> instead of <RemixServer />. This way, you're not bound to the convention of file-system routing. This is the same convention which makes nextjs problematic for react-native usage, but nextjs is less configurable in that regard, so I see nextjs as a kind of dead end for this purpose.

2. Another solution for navigation might be to declare remix routes using the component-based approach of react-router. I'm not sure if this is possible with remix, but since it's built on top of react-router, it's worth investigating. If this is possible, then it might be easy to write wrapper components which will render a react-navigation component in mobile, or a Route, in web. Or you could have a .native. and .web. file for routing config, and at least, they're defined in a very similar, mirrored way.

3. And lastly, another (less fancy) solution might be to just recreate a file-system hierarchy for routes, but each file will only be re-exporting the contents of the real file. So each route would be saying export * from "@screens", and export {default as MyComponent from "@screens". Luckily remix does allow path aliases. The only problem is if your monorepo organizes these files in a folder that is outside the main remix directory, I don't know if esbundle would have issues following paths above its own directory, as is the case with the metro bundler (This is the reason why react-native that can't follow symlinks, or paths outside the project root directory)

[kiliman]

FYI Remix does not require file system based routes. That’s just the default. You can define your own routes via remix.config.

https://remix.run/docs/en/v1/api/conventions#routes

[MiguelNiblock]

Thank you @kiliman . That is great to know. I love the concept of Remix as a whole, and see it as a strong alternative on par to nextjs. The only other obstacle I personally have is having to pre-compile modules that are shipped untranspiled to npm. I've seen from other discussions here that it's perfectly possible to do a pre-compilation locally and take advantage of the faster esbuild compiler. However, I'm not familiar with this approach and can't find good examples of it being put in practice, so I'm a little deterred for now. At some point though, I would like to give that a shot.
Theoretically, I assume I would need to install babel locally, and call babel commands directly, specify an output directory within my project root, and then... would I import the contents from this directory into my other files? Sounds straightforward, but I fear it's not haha

[xinha-sh]

For routing https://software-mansion-labs.github.io/react-native-url-router/docs/overview/ can be used as it uses react-router

[MiguelNiblock]

@tyrauber Thank you for this creation! And that comment summarizes what I think is the next trend in the path for react-native to become truly universal, which is react-native as first-class citizen on web.

I'm experimenting with a similar boilerplate idea, but using nx instead of turborepo. I'd like to mention another potential ssr framework with good support for react-native-web is Razzle. They even have a ssr template for rnw with razzle in their repo. Razzle seems very similar to remix in some ways, and perhaps even more bare-bones which might be a good thing.

[maiieul]

Just for reference, I haven't tested it out yet, but it seems you can use remix with capacitor for an all-platform development approach. Seems promising to me.

[skyriverbend]

@nandorojo have you had any thoughts/updates on this since you first made the post? I've been working with Solito/Next/Expo (incredible work, btw)... but it would be amazing to replace Next.js with Remix. Honestly, I'm surprised more work isn't going into this approach. I think what you've done with Solito is the future of development, but sometimes it feels like you're the only one working on the problem!

@tyrauber it looks like you've done some great work. I see the repo hasn't been updated in 5 months. Did you run out of time to work on it, or did you run into some hard problems?

[nandorojo]

I haven't. There doesn't seem to be interest from the Remix team as far as I can tell. The best way to get their attention is probably to build something like solito-remix, but it isn't on my radar at the moment since I'm using Next.js.

[tyrauber]

Hi @jonlemmon, haven't had the time. I've been meaning to update both Expo and Remix to current versions.

The two areas of exploration I see here are:

• shared navigation between Expo and Remix, with react-navigation, or potentially building upon @EvanBacon's current experiments in dynamic routing
• a react-native-(web) Form component, that would render a form element for react or input/api component for react-native.

Those are the two developments in my opinion that would open up integration and code reusability between expo and remix.

[moishinetzer]

I haven't. There doesn't seem to be interest from the Remix team as far as I can tell. The best way to get their attention is probably to build something like solito-remix, but it isn't on my radar at the moment since I'm using Next.js.

This would be an incredible thing to have in the community and a great asset for sure. I'm sure there are many others like me that would love to use Remix for native platforms...

[mikeylemmon]

Update (5 Oct 22): The hydration errors mentioned in the first two sections of this post have been resolved. The third section ("On the presumption that these hydration problems can be resolved...") is now the most relevant to the overall discussion.
. . . . .

I've been digging into this for the last few days, focusing on just getting react-native-web (RNW) and compatible libraries working in Remix (i.e. avoiding any monorepo/routing/solito-ish aspects for the time being).

I’m finding that with current versions of remix (1.7.2), react (18.2.0), and react-native-web (0.18.9), even the simplest possible use of RNW (adding a single RNW View to a page) results in a hydration error:

Warning: Expected server HTML to contain a matching <meta> in <head>.

Open in CodeSandbox (source code)

This has similar symptoms to #2947 (sans crash), but it occurs even in incognito mode when there are no active browser extensions.

---

From there, I tried following the process outlined in @HorusGoul’s blog post (mentioned above by @tyrauber) for integrating RNW into a Remix app, and I ended up encountering a different hydration issue — the same one that @HorusGoul reported at necolas/react-native-web#2326. From what I can tell, that issue was incorrectly closed based on a misreading of @HorusGoul's example code. The hydration error:

Warning: Prop `dangerouslySetInnerHTML` did not match. Server: "[stylesheet-group="0"]{}..." Client: "[stylesheet-group="0"] { }...

Open in CodeSandbox (source code)

If you open the CodeSandbox or clone/run the code locally, the root page loads with the client and server styles markup displayed side-by-side. The client-generated styles are fairly different from the server-generated ones, e.g:

Client styles:

<style id="react-native-stylesheet">[stylesheet-group="0"] { }
body { margin: 0px; }
html { text-size-adjust: 100%; -webkit-tap-highlight-color: rgba(0, 0, 0, 0); }
...
[stylesheet-group="2"] { }
.r-borderColor-1awa8pu { border-color: rgb(101, 119, 134); }
...

Server styles:

<style id="react-native-stylesheet">[stylesheet-group="0"]{}
body{margin:0;}
button::-moz-focus-inner,input::-moz-focus-inner{border:0;padding:0;}
html{-ms-text-size-adjust:100%;-webkit-text-size-adjust:100%;-webkit-tap-highlight-color:rgba(0,0,0,0);}
...
[stylesheet-group="2"]{}
.r-borderColor-1awa8pu{border-bottom-color:rgba(101,119,134,1.00);border-left-color:rgba(101,119,134,1.00);border-right-color:rgba(101,119,134,1.00);border-top-color:rgba(101,119,134,1.00);}
...

@tyrauber I also tried your code from remix-expo for this (it is slightly different from @HorusGoul's) and got the same result. (Open in CodeSandbox) (source code)

At this point it's unclear to me whether these hydration issues are coming from react-native-web, remix, these specific implementations of stylesheet rendering, or some combination of the three. @tyrauber and @HorusGoul, first off, thank you for sharing your work! And second, can you confirm if you're seeing the same thing in your projects? @HorusGoul, I'd also be curious to know how you came up with the solution you demonstrate in your blog post — is there any documentation or reference code that you based your implementation on?

---

On the presumption that these hydration problems can be resolved, I started experimenting with modding remix’s esbuild configuration to enable support for community RN packages. I focused on two main build configuration changes that are required to enable compatibility with the RN ecosystem:

• Prioritizing .web.<ext> files over .<ext> files when resolving files imported with implicit extensions
• Aliasing imports of react-native to react-native-web

To those ends, I modded @remix-run/dev to add support for two new config options:

• resolveExtensions: value passed through directly to esbuild's resolveExtensions option
• resolveAliases: value passed to esbuild-plugin-alias, which is added to the list of build plugins if resolveAliases is defined

Here’s how the new config options can be used to enable compatibility with react-native:

// remix.config.js
/** @type {import('@remix-run/dev').AppConfig} */
module.exports = {
  // ...
  resolveExtensions: [".tsx", ".ts", ".jsx", ".js", ".css", ".json"]
    .map((ext) => [`.web${ext}`, ext])
    .flat(),
  resolveAliases: {
    "react-native": require.resolve("react-native-web"),
  },
}

Using my remix mod, I was able to get the arbitrarily-selected expo-linear-gradient working in a Remix app:

Open in CodeSandbox (source code)

A glance at @oblador's readme for react-native-esbuild suggests that these additional config options might not be the only changes required to enable full compatibility with some packages in the react-native ecosystem (e.g. it's unclear if additional flow-stripping/custom-main-field-resolving plugins would be needed to support some RN(W) community packages, and, if so, how widespread that need would be).

As noted in #2168 and #2437, the remix maintainers are understandably resistant to creating esbuild-specific user-facing APIs. It’s unclear if these two new config options I've added would run afoul of the maintainers' philosophy as the options would be pretty trivial to implement in other bundlers (and would likely be similarly trivial in any yet-to-be-built bundlers), but if the maintainers aren’t comfortable exposing/supporting this level of control for users then another approach still within remix could be to wrap the changes up into a single reactNativeCompatibility boolean option that would apply the full set of config changes under the hood, thus keeping surface area changes to the user-facing API more constrained. And if the maintainers aren’t keen on either of those approaches, then a last resort would be to use (or wrap) https://npm.im/patch-package or remix-esbuild-override to manually patch remix's esbuild configuration. Note that I am not trying to get my remix mod upstreamed right now, just trying to feel out the contours of what a solution here would look and feel like.

---

After all of this, I am now left pondering: how do we start figuring out what's going on with these hydration errors? Do those css discrepancies look familiar to anyone?

[mikeylemmon]

I've created two monorepo examples for using shared components with with Expo:

• https://github.com/mikeylemmon/remix-rnw/tree/monorepo-expo
• https://github.com/mikeylemmon/remix-rnw/tree/monorepo-expo-router

"monorepo-expo-router" uses @EvanBacon's new expo-router, a beta/RFC module that adds filesystem-based routing to expo apps. It's awesome. Intuitively I'd like to have unified fs-based-routing between expo and remix so that the DX feels like it does with expo-web, where platform-specific divergences can be managed solely through file extensions (.native., .web., etc.) and platform detection. This isn't immediately possible unfortunately, as expo-router is going for more Next-ish filename conventions, meaning parallel filesystem route trees need to be built for both expo and remix, even if the file contents are identical aside from the root layouts (as they are in my example). User-configurable matchers in expo-router could enable a very light-weight solution to this, but short of that another option could be to use remix.config's routes function to dynamically crawl an expo-style route tree into remix.

Even without unified filesystem routing, it's all feeling pretty cool — I can have my remix and iOS apps up side-by-side, modify a shared component, and both apps auto-refresh with the changes ✨! Proper <Link>, useRouter(), and useParam() implementations are the main bit remaining to get effective parity with solito.

[L42y]

@mikeylemmon splendid job! Exactly my dream setup

[rogerchi]

@mikeylemmon Do the recent changes in 1.11 for CSS bundling change your solution? We've been trying to get NativeBase working in Remix since our standard RN design language is implemented in it and have been struggling.

[alexluong]

@rogerchi have you had any luck with NativeBase & Remix since?

[rogerchi]

@rogerchi have you had any luck with NativeBase & Remix since?

No, did not figure it out and have not tried in a while unfortunately.

[Jarrodsz]

For a newbie on react native or ionic what would you guys suggest as a good repro to learn how remix and react native work?

are there any up2date examples that use above discussed innovations? I wanted to tryout writing wn app for an opensource project im on.

[Jarrodsz]

Any updates repros examples on this please?

[Jarrodsz]

Any updates repros examples on this please?

[kaumac]

It's too bad this discussion "died".

I'm starting a new project that has both native and web apps.
I'd love to use remix, but the benefits of using remix don't come close to the efficiency/productivity gains that RN+Next provide. I'd definitely use Remix if Remix+RN was possible.

This would also give Remix tons of exposure from the RN community considering it would be the only framework (other than NextJS) to support full cross-browser support.

But considering there's no engagement from the maintainers I'm probably just ranting to an empty room here 😂

[kaumac]

@tyrauber Expo web is far from being as feature rich as Remix or Nextjs unless you're building simple apps.
That's why @nandorojo did the amazing work with Solito that binds NextJS and Expo together. I currently have a full feature NextJS app and 80% of my codebase is shared between Expo and NextJS. NextJS is deployed to Vercel as a normal server app and native is bundled.

The point is not really to use React Native inside Remix, but rather to bind Remix and Expo to work together in parallel with navigation/routes working between them.

The point is mostly navigation bindings so for example you can have a /login route in Remix and the same on Expo and have a "GoToLoginButton" that is shared between them and the navigation system works on both platforms.

[jkhaui]

I'm more curious as to why there's even less appetite for a Capacitor-based webview approach.

I get that it's not as "native" as using RN, but ultimately it's a much shorter path to a cross-platform system, and would have far less moving parts. I think both RN & Capacitor-based solutions should exist to provide users with the choice.

But yeah, the total lack of interest in mobile support by framework "influencers" has me convinced modern web dev is focused on the wrong things. The data is clear, mobile has surpassed desktop as the primary means of consuming digital content.

Therefore, We need portability and cross-platform support. Not perf micro-optimisations and reinventing data fetching for the 1000th time.

[redbar0n]

@jkhaui You might appreciate this article detailing the various mobile crossplatform tech choices: https://magnemg.eu/the-different-tech-strategies-for-building-a-cross-platform-app

WebView based approaches are disfavored by some because WebViews are underpowered, especially on iOS. But yeah, such WebView approaches was a much shorter/faster approach to a single crossplatform codebase.

Until the combo of React Native + React approaches came along, such as Tamagui.dev coupled with Solito (unifying NextJS and Expo). Which is now the gold standard for crossplatform development (if you want to achieve maximum codesharing), imho.

Until someone decides to make solito-vite so that you could use Remix or any other Vite based solution, instead of NextJS, together with Expo.

nandorojo/solito#157

[mikeylemmon]

The reason this effort died for me personally is that my particular use case shifted away from Remix, but the changes required to support React Native Web are pretty minimal (or at least they were two years ago, see mikeylemmon@b0e79b9). This might actually just never have come to the attention of the maintainers? If you're really interested in the Remix+RNW combo I'd suggest chatting with a maintainer to see whether their stance is interest, indifference, or active resistance, and if it's not the latter then try porting my commit to be up to date with the main branch and make a PR. That said, however, I'd probably only start that journey if I knew I was 100% tied down to Remix, as at this point expo/expo-router and Tamagui/Solito are much better starting points, with some pretty impressive features¹ coming down the pike. There's exciting momentum in the native+web space, just not here!

Footnotes

1. https://www.youtube.com/watch?v=BK2xbPW2uUU ↩

[jkhaui]

@jkhaui You might appreciate this article detailing the various mobile crossplatform tech choices: https://magnemg.eu/the-different-tech-strategies-for-building-a-cross-platform-app

I love that article! Thanks for sharing.

I remember we discussed this last year. On my end I got busy with other things but want to tackle this properly again.

Seeing as none of the react frameworks do what I want, screw it, I'm going to try and build my own again. I've found Waku to be a promising meta-framework to build a cross-platform solution on. It's minimalistic and has RSC support

Right now I'm focused on deep integration with react-navigation. The eventual goal is to have an expo-like solution but within a single web framework. Then I might take inspiration from tamagui's approach to cross-platform UI

Wish me luck! (Or maybe I should really just use expo + solito + tamagui at this stage)