fix(qwik-city): fix redirect with search params

[octet-stream]

Overview

I am not sure if my issue is related to #6103, so I decided open a PR with the fix for my issue. This PR changes how qwik-city-component handles URLSearchParams changes within same route segment.

What is it?

• Feature / enhancement
• Bug
• Docs / tests / types / typos

Description

This PR replaced isSamePathname with isSamePath so that the URL will be updated after redirect.

Use cases and why

Current behavior: When action redirects within same route segment, and only changes URLSearchParams, Qwik ignores the change of the URL, but the data on the page is updated.

After this change: The Qwik updates the URL, along with data refresh, just the way it works in browsers.

Reproduction demo can be found here: https://stackblitz.com/edit/qwik-redirects-er3vm8-36vtnr?file=src%2Froutes%2Flayout.tsx&view=editor

Checklist:

• My code follows the developer guidelines of this project
• I have performed a self-review of my own code
• I have made corresponding changes to the documentation
• Added new tests to cover the fix / functionality

[netlify]

👷 Deploy request for qwik-insights pending review.

Visit the deploys page to approve it

Name	Link
🔨 Latest commit	79c30e6

[wmertens]

I'm not sure this isn't a breaking change, since now it will re-run route loaders where it wasn't doing that before.

If we apply this, then there's no way to opt out of this behavior. If you are updating the search string often, it will cause a lot of network requests, no?

Perhaps there is a way to opt out of route loading when the search string changes?

@mhevery thoughts?

[octet-stream]

If you are updating the search string often, it will cause a lot of network requests, no?

In my case this is expected behavior, because loader depends on the URLSearchParams to serve a data and there's no way I can think of to know from the client if the server depends this data. This is also how this works in browsers: If you click a link, or return a redirect response with Location header, your browser will send a request to the url from the Location header, then update the URL in the address bar and render that page, just as if you clicked a link. You can open my repro, disable JavaScript and try update the filter. The current behavior in Qwik is that it uses default behavior for fetch, which is to follow redirects (fetch sends a request, and if 3xx status code occurs it checks for Location header, and if it set to a URL, it will automatically send a subsequent request, then return the result of that request as Response, I think this is where redirect behavior is described in spec https://fetch.spec.whatwg.org/#http-redirect-fetch). The only missing part is that Qwik will not update the URL after such response is received. At least this is how it works in my case (which is URLSearchParams change).

I can also confirm that there're might be use-cases when developers want to update URLSearchParams without triggering navigation, given that such discussions exist: remix-run/react-router#9851 so maybe having an option to opt-out is something to consider at least.

Also, when I tested my solution, it seems like (even in dev mode when I tested it manually) Qwik will not re-send a request, and rather re-use what fetch already returned after the redirect. Am I right?

[pkg-pr-new]

Run & review this pull request in StackBlitz Codeflow.

commit: 79c30e6

@builder.io/qwik

npm i https://pkg.pr.new/@builder.io/qwik@6410

@builder.io/qwik-city

npm i https://pkg.pr.new/@builder.io/qwik-city@6410

eslint-plugin-qwik

npm i https://pkg.pr.new/eslint-plugin-qwik@6410

create-qwik

npm i https://pkg.pr.new/create-qwik@6410

---

templates

• default

[gioboa]

I tested your code locally and it's working fine.
This is a great fix btw. With the old code routeLoader$ is running without changing the URL and this is not correct at all.
With your fix @octet-stream the problem is solved.
Thanks 👍