Navigation API

[jordanw66]

What is it about?

No response

What's the motivation for this proposal?

Back when I initially reworked the SPA resume/history/state/scroll restore, I was envisioning possibilities with Navigation. I had some unforeseen life events and no time then, the implementation isn't in Firefox/Safari yet anyway but I think it's not too far out based on issue trackers.

It's already being used in the wild on reddit for example as seen here: webcompat/web-bugs#136535

Some initial thoughts on how this affects Qwik (City/Router):

• No manual scroll restoration required, all the various edge cases disappear
• No dependency on history state, no need to override history.push() and history.replace()
• The above means Firefox-specific issues with history state go away, no need for compat code
• A simple check tells us whether the current page was arrived at via SPA:

navigation.entries().some((e) => e.id !== navigation.currentEntry.id && e.sameDocument)

• No need to preventDefault() on Links anymore, potentially no need for even onClick$ handler. Only the prefetch handler and an attribute tag to tell QC that this should be SPA and to intercept() it
• Simplifies all navigation code to a single handler on the QC component (Links, useNavigate, Form, etc)
• canIntercept and formData on the event simplify much of the navigate logic
• Potential to easily solve the #hash issue on useLocation()
• Simplifies the experimental usePreventNavigate() which needs to workaround popstates and history and navigate logic
• Potentially allows advanced functionality for users to easily hook into and modify/extend navigation behavior
• And more I'm sure I haven't thought of yet

These possibilities mean much of the code can be restructured and simplified greatly for a more reliable user experience. However, complexity increases dramatically if you have to support the legacy code, with some hard issues and edge cases that would require undesirable tradeoffs.

Any thoughts? When it does land in Firefox and Webkit, should Qwik try to make the legacy-support approach work or should it go all-in on a navigation refactor and target a specific breaking future version? Does QC make any guarantees about legacy browser support?

Note that there are Navigation polyfills but aren't sufficient because it's impossible to replicate all of the required behavior

Proposed Solution / Feature

No response

Links / References

No response

[wmertens]

@jordanw66 off the cuff first idea: could we have two implementations and load the appropriate one based on capability?

Or are the APIs too different

[jordanw66]

Hard to say upfront, I think it might be possible but it presents many challenges: - A lot of code in the QC component, Link, Form, etc would be entirely obsolete by this so you'd have to maintain almost two separate version of these - Because Qwik starts on the server and continues on the browser, some things would probably require some thought and might be impossible to do during SSR without brittle user agent checks, or requiring duplicate or unnecessary client code/handlers - Scroll restore in Navigation is automatic, without it you must do it early and synchronously to prevent jumping, requires shipping double resume code - Some functionality is just impossible without Navigation, especially around popstates, and wouldn't replicate for legacy browser versions - Navigation-related features and hooks might simply not work or not work as expected or have unintuitive quirks that are not obvious to developers in legacy browser versions - etc I haven't thought too deeply, it certainly might be possible, however the hard limits of the legacy history API make be cautious about impossible blockers down the road. It could be worth trying but I wondered if maybe just setting a breaking change on a version 3.0 or something and whether time is better spent focusing resources on making UX/DX as streamlined as possible or creating features that weren't previously possible?