[🐞] SPA resume (probably) needs to be fixed for upcoming v2 changes about qwik HOT 4 OPEN

Hmm I'm afraid I don't understand. Apart from the contexts' data that Link uses, what needs to be shipped to the client to enable SPA?

The useNavigate context needs to be shipped for SPA, this is big as it requires all of Qwik City, that's why SPA only resumes if it was already included on the page because the dev used Link or nav().

If this isn't present then it falls back to simply reloading the page with location.href when a popstate occurs. This will usually only occur on a "leaf node", a page arrived at from a navigate but which doesn't contain any Link or nav itself. (anti-pattern but needs to work anyway)

To make it more clear, this resume is included on every single Qwik City page even MPA. Except it's just a tiny couple-line shim, the actual script is gated behind a history.state check, this checks if the page was ever SPA, if it was then a much larger (pre-cached during previous SPA) script is manually loaded (bypasses the Qwik loader), this big one actually performs this resume functionality. But only if the context is already present on the page, because that pulls in many kB of Qwik City. It's like a multi-stage boot process, because we want to minimize footprint to near 0 when SPA is not used.

When a user refreshes a page that was arrived at through SPA, or re-opens browser, etc. the navigate context is lost. This whole contraption is designed to track and restore scroll positions no matter what the user does or how badly things get messed up and it has to do it without impacting MPA; it always just works and it's nearly free.

Hope that explains everything. And like I said above, there's a couple line solution to fix this problem and maintain current limitation (dependence on Link), I updated the issue to explain.

from qwik.

Thanks Jordan! Question: how about always including the spa context, would that also solve it? Is it that huge?

from qwik.

Thanks Jordan! Question: how about always including the spa context, would that also solve it? Is it that huge?

I don't think this is possible, the useNavigate context requires the full Qwik City meta framework to also be present. Qwik's feature of choosing between SPA or MPA dynamically without having to make a permanent design decision constrains this because MPA doesn't want to load anything to do with SPA.

When I first designed the SPA resume and scroll restore it was clear to meet the demands for all cases, it had to exist kind of outside Qwik & Qwik City such that it will hook in to useNavigate if it's already included on a page to re-bootstrap but not actually trigger any dependency if it's not. This also solves edge-cases as explained above.

With that said, this can be fixed very easily by simply including a new attribute with a magic string on the Link component and selecting on that. This wouldn't require any other changes I think. But perhaps maybe someone can find a better way to expand functionality to work for all cases of useNavigate like nav() or custom Link components instead of relying only on the official Link.

from qwik.

Hmm I'm afraid I don't understand. Apart from the contexts' data that Link uses, what needs to be shipped to the client to enable SPA?

from qwik.