Router "navigating" state when waiting for server

[rmarscher]

With React 19 streaming and Suspense, we can get very fast time-to-first-byte for dynamic pages. But sometimes, there are factors like poor network conditions that might introduce time between when someone clicks a link and receives the server response.

It would be great to have something like SvelteKit's navigating object in the router properties when the "change router" process has started but it is waiting for the server to start streamining.

https://svelte.dev/docs/kit/$app-state#navigating

React Router also has something similar
https://api.reactrouter.com/v7/functions/react_router.useNavigation.html
https://api.reactrouter.com/v7/types/react_router.NavigationStates.html

[rmarscher]

I wonder if these router properties are a reason to add jotai as a dependency of waku. Or maybe a separate jotai-waku-router package to implement it. It feels like a good use for atoms.

I see next/navigation moved the router properties to individual functions like usePathname. I wonder why. Maybe it was to force more granularity so devs avoid re-renders. Maybe react compiler avoid needing to think about that.
https://nextjs.org/docs/app/api-reference/functions/use-router#migrating-from-nextrouter

[dai-shi]

I use useTransition for such cases, but is it different from your requirement?

[rmarscher]

Screen.Recording.2025-02-20.at.11.32.51.AM.mov

[rmarscher]

I use useTransition for such cases, but is it different from your requirement?

Oh... I see there are pending and notPending component options for Link. Hmm. I see changeRoute uses startTransition... that is the transition that would be nice to track from a global part of my app.

Looking at that network screen recording above, I see some data is sent in the response stream before any of the updated page element has started streaming. This was on my fast home internet so the response was received almost immediately. If I throttle the network down to 3G, I can notice a delay before the response is received.

The router path prop does not updating until after the page has started rendering. That is the expected behavior - but I'm unsure how that works looking at changeRoute. It looks like we call the scroll handler and setRoute immediately after refetch. But maybe React some how awaits the refetch because it is inside startTransition and calls use(RefetchContext) - so React somehow knows how to delay the rest of the transition function??

[rmarscher]

React some how awaits the refetch because it is inside startTransition

Yeah, I think that is correct.

It looks like it might be possible to put Suspense outside the Router in main.tsx to show a global loading state. But that's not what I'm looking for. I just want to add a subtle progress indicator to add some feedback to the page while it's loading.
https://react.dev/reference/react/useTransition#building-a-suspense-enabled-router

[rmarscher]

I tried some ideas here. https://github.com/rmarscher/waku-long-ttfb
https://waku-long-ttfb.martiandev.workers.dev/

I was able to get it to behave the way I want using Suspense and by wrapping Link to add an onClick handler that updates an atom.

[dai-shi]

I'm pretty sure there are some cases we want more control, and maybe with atoms.

However, I'm still not sure if what you are looking for can be covered by useRouter and useTransition.
https://stackblitz.com/edit/github-y9bu44hf?file=src%2Fcomponents%2Fheader.tsx%3AL8
☝️ Tried something (and noticed tailwindcss v4 issue in stackblitz), and it's my bad. I thought const [isPending] = useTransition(); would work, but it doesn't.

This feels like a React issue, not a Waku issue. I wonder what would be the best practice in React 19. For now, I think what's best is to use useTransition where you want or above the tree and pass startTransition via a context, and specify it in Link or use it with useRouter. This doesn't work if you need more info than boolean (and your custom Link looks good in that case.)