Support the Navigation API

[LifeIsStrange]

What problem does this feature solve?

Chromium 102 has been released stable, which means that Chrome, Edge, Opera, Brave, Vivaldi, etc and Electron supports the Navigation API
https://chromestatus.com/feature/6232287446302720
The Navigation API is the successor of the History API and is better suited for SPAs.
Therefore, routers should allow to target and leverage it.

Why should this feature be included?

The existing window.history API is hard to deal with in practice, especially for single-page applications. In the best case, developers can work around this with various hacks. In the worst case, it causes user-facing pain in the form of lost state and broken back buttons, or the inability to achieve the desired navigation flow for a web app.

What does the proposed API look like?

see the spec https://chromestatus.com/feature/6232287446302720

[posva]

I'm aware and active in the open discussion of the API and it's still too early to adopt. It will be adopted possible.

[zkulbeda]

Hi @posva, it seems Navigation API was successfully merged into html spec (whatwg/html#8502). Is it worth to reopen the issue? This API offers a completely different way to manage user navigation and some advantages such as

• Native page loading state
• Native aborted navigations (with AbortSignal)
• Native scroll position restoration
• Setting the entry's state without navigating
• Native canceling of the navigation (i. e. without need to go back on cancel)

The current architecture of the router based on listening to history events does not allow you to create a new history adapter that would listen to the end of navigation using promises and notify the browser of the end. And also how navigation cancellation is implemented inside router instance, it's impossible for the adapter to know that navigation is cancelled. It's hard to imagine how many changes will have to be made to the existing solution, maybe it worth writing version 5.0.0 of the package?