Fetch-as-render

[avedetvedea]

Will the new router allow eager navigation to facilitate fetch-as-render? Asking for Relay. Also the WIP doc says that Suspense boundaries: This feature is not currently implemented in React Native/Metro but.... Didn't RN 0.69 came with full support for Suspense? (equivalent to React 18)

[EvanBacon]

Will the new router allow eager navigation to facilitate fetch-as-render?

Potentially. I'd like to allow for conditionally forcing certain routes to be online-only as this would greatly improve the amount of code an App Clip could support.

Didn't RN 0.69 came with full support for Suspense?

No. We're working with the Metro team to implement this so we can split all routes automatically (in development). We have a prototype working but it has some Fast Refresh issues.

[avedetvedea]

@EvanBacon Hey again. On estimate in which iteration (2.0, 3.0 ...) would you say expo-router would be getting loaders, if ever, to be able to both

• preload queries automatically based on route (or on route+route variables if a page has different strategies) and
• pass query references with navigation through loaders? (for example in Relay these query references that would be inputted into preloaded queries that were initiated on click events have methods in them, like dispose query, which prevents passing them directly through the navigation due to serialisation)

[avedetvedea]

I understand that currently there is none, and my question was if that was on the horizon. The request is the ability to automatically load queries based on the route, to implement fetch-as-render, i.e., the rendering and fetching the data would be occurring independently and in parallel, facilitating Suspense

[MaxAst]

would love to see relay's render-as-you-fetch capabilities baked into expo-router as well. The perfect routing solution would check if a page exports a gql query string and then automatically loads the query when clicking a link to the given route. It would also automatically dispose the query when leaving the route. The queryRef would be passed as a prop to the page component (e.g. like nextjs pages using getServerSideProps), so that it can pass the queryRef down to components that need it for their graphql fragments.

The relay team recently added an example for nextjs v13, where implementation ideas could be borrowed from

[avedetvedea]

Also, going down this road, useTransition should be included at the router level to optionally defer updates. I see that Tanstack will be exporting a loader library, I guess developed during development of their new router, which may also be helpful (Tanner will be including every trick of the new React in his router and says that he will be writing a RN adapter, so may be helpful to watch that space too).

@EvanBacon The fetch-as-render is where React is headed to and is a big deal regarding the user experience; I hope it will appear in v2, and expo/router will be the first library to support it (other than the experience of not having loading waterfalls, useTransition based deferred updates and so forth, as mentioned the loaders will also help to pass some async goods directly to the props that are non-serialisable, which will solve a lot of problems for anyone integrating Suspense in their apps)

[avedetvedea]

https://beta.reactjs.org/reference/react/useTransition#building-a-suspense-enabled-router

"Note
Suspense-enabled routers are expected to wrap the navigation updates into transitions by default."

So apparently transitions should be the default, but the opposite, not to mark a route change as a transition (i.e. as urgent), may be provided.

[tslater]

I'm not entirely sure what the request is here. There are currently no data fetching policies built in to Expo Router.

Just to clarify, this isn't about coupling with any sort of data fetching policy, but taking advantage of the deep react features that the react team has designed specifically for a routing use case. The idea is to take full advantage of the new architecture of React in the way it was intended.

[avedetvedea]

Hey @EvanBacon. I'm really excited to use the new router. I would like to ask what is the current roadmap on loaders, which I really eagerly wait since last year to make the switch (which will solve a problem react-navigation never solved). To reiterate, I think fetch-as-render, non-urgent transitions and auto Suspense/ErrorBoundary wraps are exactly what React is and its direction at, and hopefully the new and extremely competent expo/router will provide these mechanisms alongside its currently shared goods sooner than later for that reason.

Were you able to read the discussion react-navigation/react-navigation#11152?

[tslater]

@EvanBacon First off, ExpoRouter is amazing. So excited for v2.

I'd like to add a comment here that I think much of the React community really doesn't understand the full benefits and motivations all of the hard work Meta has been investing in React in terms of the suspense API. There's really a lot of potential to decrease loading times and give the developer control over the perceived loading time. Really, most of the large changes to React have bene built around Suspense (with the Relay framework they mention above being the flagship use-case).

A modern react-focused router should absolutely be suspense compatible. This is this biggest omission of React Navigation is the fact that it doesn't support suspense. The link above is outdated, but here the React docs outline how to build a fully-react suspense enabled router:
https://react.dev/reference/react/useTransition#building-a-suspense-enabled-router

You'll also see numerous references to router support in the main documentation:
https://react.dev/reference/react/Suspense

Would love to get a "yes", "no", or "maybe" on if this is in the cards or not.

[avedetvedea]

Above discussion is not "outdated". Both Satya and the community added their possible solutions and explanations which cannot change to be outdated

[tslater]

To be clear, not the discussion, just the URL, there is a new non-beta URL.
I'm 110% pushing for this with you @avedetvedea!! Do you have links to other discussions you can share here?

[avedetvedea]

Hey @tslater, I thought you were talking about the discussion link. I was trying to point out the importance of the most recent inputs on that discussion, as both Satya's solution is pretty straightforward (and he is the react-navigation maintainer, which will merge with this lib at some point) and the charts there will probably help Evan to understand what's up (who may not know Relay or cutting-edge Suspense architectures).

We had similar discussions in the GQL Discord's Relay channel, which basically overflown to here. Unfortunately, as you can see the initial response by Evan that the most important aspects are both not a priority and they are not understood (e.g. the discussion is around Suspense capabilities and thus eager navigation, but Evan responded with online/offline architectural decisions).

We have been trying to tell the importance of this exactly like you did, with stressing, but so far the technical problems they have been solving are prioritised differently, and to be frank, differently than React - I don't know how this sentence can be improved to be more emphatic :/

[tslater]

Yeah the goals of Expo Router are really great. I think the declarative file structure, type safety in v2, linking, compatibility with web, and other focuses are honestly incredible...but, to your point, the React core has a clear focus on how rendering should be prioritizable and fast. This does not seem to be in the current goal set of Expo Router. As React Native developers, ideally we wouldn't have to chose between the two. Hopefully we can get @EvanBacon to see this vision here!

[tslater]

Or maybe this is already on his radar?

In the context of talking about development vs production suspense:
"Both forms will improve our ability to add standardized data fetching in the future."

#309