Integrating the new Navigation API into RSC framework #11

What makes you think that? There's no mention of precommitHandler in their codebase

Ah I think I got mixed up with react/react#33162 maybe

Wow, thanks for sending it my way 🙏 . It's ingenious, but they are cheating a bit. They're faking a navigation to show the native progress. I don't see them supporting pressing the 'X' to cancel, but you never know.

My favourite usecase for the new Navigation API is delaying the browser back/forward. The browser used to force you to show a cached page for history navigation because it updated the URL instantly (I think that's why Next.js felt entitled to add caching everywhere else as well 😆).

But that's not true anymore as you can see in the vid below. I press the back button, the browser instantly updates the arrows and progress button, but it doesn't change the URL. Then I cancel the back and the browser reverts the arrows and progress button.

Even better, you never end up showing stale data. In the vid you can see I update the person's name then navigate back and the name is updated in the list. There's no flicker because the history back waits until the new data is fetched.

Unfortunately, seems it's still too late for scroll restoration but could probably do that manually

@eps1lon I've finished the work of adding precommit handling to the Navigation router.

I've built a demo repo for you to take a look at.

The key advantages of using precommit handling are

1. Google Chrome shows the 'X' progress indicator for all navigations just like in MPA. Pressing the 'X' cancels the navigation.
2. The browser history back never shows stale data. Select a person, edit their name then press browser back and the list will show their new name.

React concurrent rendering fits surprisingly well with the precommit handling from the new navigation api. But there are points of friction.

• In Google Chrome, when the user presses 'X' to cancel the navigation, the browser kills the RSC stream. The only way to prevent the error reaching React was to wrap in a custom ReadableStream and not pass on the chunk when signal aborts. Is there a better way?
• There's a timing mismatch between precommit handling and concurrent React. The browser expects that when the precommit handler completes the UI will still be on the old page. This is when the browser stores the scroll position, for example. But React doesn't tell libraries that a background render is complete until it's committed to the DOM. This is too late for scroll restoration. Can React notify RSC routers before it commits?
  • Google Chrome on mobile takes a snapshot of the previous page so that it can show it when the user swipes back. Committing the navigation in useEffect is too late because the browser will take a snapshot of the current page instead of the previous one. But worked around this by committing the navigation in useInsertionEffect instead (this is still too late to fix scroll restoration). Is this just luck or does React guarantee the timing gap between useInsertionEffect and useEffect (it seemed to increase between React 19 and 19.2, for example)?

Here's the rough picture of how the Navigation router matches up concurrent rendering with precommit handling. Start a browser navigation but intercept it and hold onto the returned promise's resolve. Start the React background render. When React commits the background render call resolve to commit the browser navigation.

let commit;
// 2. Intercept the navigation
window.navigation.addEventListener('navigate', e => {
 e.intercept({
 async precommitHandler() {
 return new Promise(res => {
 // 3. Hold onto the resolve
 commit = res;
 });
 }
 });
});
// 1. Perform the navigation
window.navigation.navigate(url)
// 4. Start the React background render
startTransition(() => {
 stateNavigator.navigate(url);
});
// 5. Commit the navigation when React commits the background render
useInsertionEffect(() => {
 commit();
});