Post

So excited by this. Related, but kind of general question: how stable is the API? I've been going through the GitHub issues for how I might implement a "rollback" after an intercept, and it looks like there have been a few of solutions: commit: 'after-transition', event.commit(), & precommitHandler.

Do these things become a bit more stable once they are baseline? (and also, how might I determine support for precommitHandler? will `if (NavigationPrecommitController) work?`

If you reject during the precommitHandler, then the navigation is aborted, but if you want to 'roll back' after commit, then you'll need to traverse back or replace the current history state. In terms of stability, there's always the possibility of bugs, but the methods won't change now.

Is there a polyfill?

I'm not aware of a good quality polyfill. I'm not sure it's possible to build one.

I released a polyfill with pretty good good support for navigation history entries. As I start to think about how to tackle navigation transition lifecycle (Navigate event, cancellation, interceptors, etc.) I was wondering if you have any wisdom to share in the parts you think are impossible? 🙏🏼

I actually have one that I’ve been working on for the past few weeks, and I would love any feedback on it: github.com/kcrwfrd/navi... I feel quite good about supporting entries(), currentEntry, and canGoBack. I will have to start digging into navigate() @webdevs.firefox.com

I wouldn’t call it stable yet. It works by patching the history API so that you can use navigation api features in history-based framework routers. I want to make that patching explicitly opt-in so that you could avoid patching altogether and eschew history altogether for a purely navigation router

This is literally my favorite account on Bluesky and these @jakearchibald.com videos are great! Exciting to see the conclusion to the "big back button quiz" saga.