How to update the query string without triggering a request to the server?

[giopetris]

I'd like to just change the query string of a route without triggering a request to the server (without passing through the loader func), like a client side navigation. How could I do that?

Thanks!

[giopetris]

After digging more into it, I discovered that this is possible by using history:
This is the code I'm using to change the query string of my root page (/) without making a request to the server:

import { useSearchParams } from "remix"; 

const [searchParams] = useSearchParams();

...

// Inside an onClick render: 
const qs = searchParams.toString();
history.replaceState(null, "", qs ? `?${qs}` : "/");

It would be good to know if there's other ways though, this feels a bit hacky.

[nickhow83]

I'm not even sure if this is still relevant, but in the version I'm working with now, useSearchParams has a get and a set in it's tuple.

something like:

const [searchParams, setSearchParams] = useSearchParams();

setSearchParams({}); then clears all of the querystring, without doing a navigate

[na2hiro]

I made an attempt to do this client-only navigation, after sorting out different types of requests/navigations we can make to make the Remix request cheatsheet.

Navigation to URLs which only the hash (#...) part is changed doesn't make a request to the server with native <a>. Remix respects that too, i.e. <Link to="#..."> and navigate("#...") doesn't make a request to the server. My attempt is to store query in hash, like #color=red, something like:

// declaratively
<Link to="#color=red"></Link>

// or imperatively
const navigate = useNavigate();
navigate("#color=red")

I made a prototype for this idea. It works mostly ok, except one thing, which is in some cases not acceptable:

• clicking doesn't make HTTP requests for loader
• browser history works nicely
• Works both declaratively and imperatively
• Initial load on URLs with # data doesn't render with the specified data, because server doesn't get the hash part and does SSR without it

Prototype: https://stackblitz.com/edit/node-jrnx4b?file=app%2Froutes%2Findex.tsx

(Note that = and other characters after # triggers a Remix bug #936. Update to Remix to 1.2.1 or later.)

I guess if we want the server to notice a parameter in initial rendering but ignore in the following client-side navigations, we'd need another solution.

[giopetris]

Thanks for digging into it @na2hiro , and yeah, the # also seems off for me, this is used to reference a DOM element ID, not for storing data in the URL. It also doesn't support multiple values as query string does (?x=z&w=y i.e.)

[sergiodxa]

Because changing the query string means changing the URL then the correct behavior is to request the loaders.

But there's a built-in solution, using unstable_shouldReload you can check if what changed was the query string and prevent the request (this runs client-side).

That is the correct way to prevent this, and you will need to export that function on every route that may be called by Remix when the query change on your URL, so your route and their parents or child routes.

[sergiodxa]

Not every single route, only route that match the URL where you set the search param.

[meglio]

It's inappropriate to select the answer as the correct one while you are not the author of the question - I did not make that selection.

[kiliman]

Not sure what you mean.

[kiliman]

I think the only change done recently was that this discussion was marked as resolved.

[meglio]

Sorry for the confusion.