React Native Support

[tom-sherman]

Hi 👋

It would be great to start a discussion about react native and if support falls within the goals of this project.

I have a POC here: https://github.com/tom-sherman/ReactLocationNative

[tom-sherman]

Some weirdness I've encountered so far:

useErrorBoundary is required to be set to true

You need to use error boundaries right now because the dev mode error handling uses DOM elements.

This isn't a big deal to me because I would have enabled it anyway but it's a footgun when getting started and some people may want to set it to false. I'd vote for having it true by default for everyone, but that's a separate conversation 😅

Need to use import aliases to properly resolve react-location

I have no idea if this is a problem just for me but I needed to patch the metro resolver to change @tanstack/react-location to @tanstack/react-location/build/cjs, otherwise you get the following error:

error: Error: While trying to resolve module `@tanstack/react-location` from file `~/code/ReactLocationNative/src/App.tsx`, the package `~/code/ReactLocationNative/node_modules/@tanstack/react-location/package.json` was successfully found. However, this package itself specifies a `main` module field that could not be resolved (`~/code/ReactLocationNative/node_modules/@tanstack/react-location/build/umd/index.production.min.js`. Indeed, none of these files exist:

  * ~/code/ReactLocationNative/node_modules/@tanstack/react-location/build/umd/index.production.min.js(.native|.ios.js|.native.js|.js|.ios.json|.native.json|.json|.ios.ts|.native.ts|.ts|.ios.tsx|.native.tsx|.tsx)
  * ~/code/ReactLocationNative/node_modules/@tanstack/react-location/build/umd/index.production.min.js/index(.native|.ios.js|.native.js|.js|.ios.json|.native.json|.json|.ios.ts|.native.ts|.ts|.ios.tsx|.native.tsx|.tsx)
    at DependencyGraph.resolveDependency (~/code/ReactLocationNative/node_modules/metro/src/node-haste/DependencyGraph.js:311:17)
    at Object.resolve (~/code/ReactLocationNative/node_modules/metro/src/lib/transformHelpers.js:129:24)
    at resolve (~/code/ReactLocationNative/node_modules/metro/src/DeltaBundler/traverseDependencies.js:396:33)
    at ~/code/ReactLocationNative/node_modules/metro/src/DeltaBundler/traverseDependencies.js:412:26
    at Array.reduce (<anonymous>)
    at resolveDependencies (~/code/ReactLocationNative/node_modules/metro/src/DeltaBundler/traverseDependencies.js:411:33)
    at processModule (~/code/ReactLocationNative/node_modules/metro/src/DeltaBundler/traverseDependencies.js:140:31)
    at async addDependency (~/code/ReactLocationNative/node_modules/metro/src/DeltaBundler/traverseDependencies.js:230:18)
    at async Promise.all (index 3)
    at async processModule (~/code/ReactLocationNative/node_modules/metro/src/DeltaBundler/traverseDependencies.js:198:5)

Here's my workaround:

https://github.com/tom-sherman/ReactLocationNative/blob/ca2bf9a261e75f16c131e17329a2e3f2d6af4703/metro.config.js#L18-L28

Cannot use Link component

I needed to write my own link component but it's not trivial to implement all of the features.

[tom-sherman]

A separate point, it's not clear to me how I would integrate react-location into native navigation patterns with eg. https://github.com/software-mansion/react-native-screens

Any thoughts on this?

[sylfel]

In my opinion, It's complicated :-/ in react-navigation, it's "included" in sources with sometimes a fallback

I think you can add a screencontainer or a ScreenStack as a "root" component, and use a Screen as direct child (with and inside if necessary
But, using children with this is ... complicated, i don't know how to

[tom-sherman]

What I'm realising is that react-locaton, like react-router, are not really suitable for integrating with react-native-screens.

Because they are all built around rendering to a single element at a time, whereas react-native-screens is built around mounting multiple elements controlled with the activityState (or child order in the case of stack).

I do expect react-router at least to support this pattern in the distance future though, but it will come after React releases their <Offscreen> API. For now I think the only thing we can do is fork...

[SeanRoberts]

Tanner did mention this is on the roadmap on Twitter: https://twitter.com/tannerlinsley/status/1590112579468546048

It's definitely not an easy problem space.

[Byevenes]

Expo router is other option to see, include router using folder system like next 13 👀, I hope to see tan stack router in react native 🫶🏽🤍

[tannerlinsley]

An adapter won’t be difficult after we rc

[tom-sherman]

Did you have any thoughts on this comment? #207 (reply in thread)

[redbar0n]

a first draft, maybe: #207 (reply in thread)

[avedetvedea]

Since this, expo-router is now in v3. Will we able to use TanStack router with react native (expo) apps? Can we add expo-router to the comparison page? (with possibly related native/web distinction)

[tannerlinsley]

It would take some work to build the inversion of control around the actual GSX elements that are rendered for things like errors, but it would be totally possible to make this work for a react native and expo . Tanner Linsley

…

On Nov 6, 2023 at 2:31 PM -0700, avedetvedea ***@***.***>, wrote: Since this, expo-router is now in v3. Will we able to use TanStack router with react native (expo) apps? Can we add expo-router to the comparison page? — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: ***@***.***>

[avedetvedea]

It has been 1.5 years since this discussion has started, looking at that is it not reasonable to wait for anything concrete?

I see that you have a lot on your plate, very interested in Bling, too; It is just these projects don't have the same priorities as you, as expo-router v3 still have not talked about fetch-as-render, which is where React has been going for a long time now.

[tannerlinsley]

I’m not totally sure what you’re saying. Are you asking me if you should wait for this functionality vs use something else?

[avedetvedea]

yes, and if not to wait, a vague timeline? expo-router uses native navigation suite underneath (react-navigation), so not sure how your router will fare against, though

[JJosephttg]

I definitely think React Native needs this. Expo/react navigation is such a pain to work with. Especially when you deal with stack state, nesting navigators and nested navigation. Plus expo router moved to file based.

[natew]

@JJosephttg would love to get your feedback around this, I've been working on a stack that forks from it and would like to fix the issues. Can email me in profile.

[tannerlinsley]

I might be able to give this a good push, but I’m curious if there are any native companies that would sponsor the effort?

[dohomi]

I'd love to see support for Expo, that would be a real cross platform router option which is currently been missing. Expo router can do both, but devs are forced to use Metro for web.

[redbar0n]

Check out https://vxrn.dev for using Vite instead of Metro.

[helmturner]

ngl, as much as I'm excited to use this in React Native, it might actually be worthwhile to push this until react-strict-dom matures a bit.

I've got TSR working in RN without patching—I had to implement a custom history for RN, and the default error component is required, but it's working bug free AFAIK (though there may be design flaws in my implementation, but I digress).

Basically what I'm trying to say is, once react-strict-dom is a bit more feature complete, it would trivially solve every integration issue I've witnessed thus far.

[redbar0n]

If someone makes a Solito like library (2000 loc) for TSR then react-strict-dom wouldn’t be necessary.

[redbar0n]

If the goal is to support crossplatform apps (and not just have another router on RN, of which there are already many), I think the way to go is:

• Not to deeply integrate TanStack Router (TSR) directly with Expo, to get a single beefed up universal router, since they are different enough, and their goals don’t align too well (both are very opinionated, and Expo is betting on being that universal router++ solution with Expo Web). Bundle size on web etc would also likely become a problem if a beefy router drags along native specializations. @dohomi
• Not to try to make TSR work on native (to replace Expo Router), since navigation patterns on native are quite distinct from web, and there are already quite a few RN specific routers. @helmturner @avedetvedea @JJosephttg
• Not to try to use React Navigation (which Expo uses under the hood) on the web (as some are attempting elsewhere), due to the same reasons as the previous point.

But instead to use Expo Router only on native, and TanStack Router (TSR) only on web, and align them by making a custom file system route loader/adapter for TSR that uses the same file based routing conventions as Expo Router, so that instead of having two separate folder hierarchies (monorepo approach), you could have a single shared/crossplatform app directory (which is just targeted by the platform specific routers, based on aligned conventions).

You would have to use Metro to bundle for Native (as Expo Router requires it), but could use Vite to bundle for web. At least until VXRN.dev catches some more momentum. But Expo is betting on expanding their Metro integration, so VxRN might be a risky bet for future alignment with Expo. Expo wants to be the wholesale crossplatform solution with Expo Web and based on Metro, but Expo Web has a big bundle size and doesn’t support SSR (might change with Expo’s vision of RSC for RN, but SSR/SSG etc. feature parity with web frameworks like Next, Vike or TSR + Vinxi is a long way to go). So imho it’s best to take the Solito kind of approach and use each router and bundler setup for the platform they were designed/aimed for.

In summary: The idea is to have a single file system hierarchy, which is used by Expo Router on native, and TanStack Router on web.

[redbar0n]

To reiterate: The idea is to have a single file system hierarchy, which is used by Expo Router on native, and TanStack Router on web.

For Expo Router: "When a file is created in the app directory, it automatically becomes a route in the app."

For TanStack Router, it should be similar, but you also have the option to customize the routing even more on web, if you need some URL shenanigans.

[dohomi]

I love the idea of a single file system hierarchy, but my current project for example would not use it due to the fact that many pages of the router would have a total different look&feel or even functionality (mostly stripped down). I would rather have two separate starting points like native-routes, web-routes but both would share the same <Link>, and use* hooks for search and navigation.
But I totally support your vision because that feature might be a game changer and a great alternative of using NextJS+Expo

[redbar0n]

@dohomi what I was thinking was that since TSR can import the file system routes but then override in config, then for specific web routes you could override those in that web router config. Would that work? Another alternative might be platform specific layout files.

[dohomi]

@redbar0n what about TSR specific hooks which are not existent in expo router? I am not sure if for example useSearch would work for native

[redbar0n]

@dohomi yeah, those would likely have to be in a wrapper component / layout file, or give a noop on native.