Update route parameter in SvelteKit

I'd like a quick sanity check. I've got a route in svelte, /browse/[[page]]. The page param is used for pagination. I've also got filters on the same route, and those are put into the searchParam, so a full URL might look like this:
/browse/2/?name=test
/browse/2/?name=test
When I apply filters, I use goto to update the searchParams. Originally I had
goto(`?${searchParams.toString()}`);
goto(`?${searchParams.toString()}`);
That keeps you stuck on the page you're on, and your new potentially more specific filter might have fewer pages. Ideally, any new filter action would send you to page 1. I could of course change the page parameter to also be a searchParam over a route parameter, but that would complicate setting the filter, so right now I'm doing this
const urlparams = ...some magic sauce...;
const pathname = $page.route.id?.replace('/[[page]]', '') ?? $page.url.pathname;
goto(`${pathname}/?${urlparams.toString()}`);
const urlparams = ...some magic sauce...;
const pathname = $page.route.id?.replace('/[[page]]', '') ?? $page.url.pathname;
goto(`${pathname}/?${urlparams.toString()}`);
which works just fine, but it feels hacky. I'm hoping I'm missing some helper function in Sveltekit that lets you modify a route and get a new path string to feed to goto. I don't anticipate this causing problems down the line, I'm pretty sure this would work even for other routes (say a /admin/users/[[page]] route) without modification, but it's not as smooth as I'd expect from sveltekit and that usually means I'm missing something. So the question is, am I missing something? And while I'm posting anyway, is my current solution causing any code-related nausea in anyone?
18 Replies
b1mind
b1mind•13mo ago
I'm confused Have not had coffee yet but why are you using goto? also why [[page]] not [page]*? Is this all client side? (tauri app w/e)
Jochem
Jochem•13mo ago
[[page]] so that /browse works as well, I'm used to making my pagination optional for some reason goto because I'm doing preprocessing on the form data to build the URLSearchParams object and don't want to just submit the form and this isn't the tauri app anymore. It's code in a component, though the only time it'd be triggered is from user action on the frontend, so technically yes, all client side
b1mind
b1mind•13mo ago
SvelteKit docs
Loading data • SvelteKit documentation
b1mind
b1mind•13mo ago
I'd still use the load() and return a redirect probably if you are using form actions too you would be able to check before submition and have access to formData oh you throw redirects mb xD
Jochem
Jochem•13mo ago
how so? I'm just using goto
b1mind
b1mind•13mo ago
I mean I would forgo goto period that is some nasty client side only thing I don't touch it >.>;; Form Actions You shouldn't need to hijack anything
Jochem
Jochem•13mo ago
so you'd have a PageAction in +page.server.ts that would just take in the filter fields and the current route? I'm not sure I see the functional difference, other than adding a server hit
b1mind
b1mind•13mo ago
Cause its a real form xD Would work without JS or with it (and you could then do fancy client side enhancment)
Jochem
Jochem•13mo ago
hm, fair enough. It wouldn't necessarily change the original question though, I'd still have to do that serverside, just with redirect instead of goto
b1mind
b1mind•13mo ago
https://kit.svelte.dev/docs/form-actions#anatomy-of-an-action-redirects Yes but if you avoid goto SvelteKit takes the wheel and you get that sexy transional app that works in all add use:enhance that is *
Jochem
Jochem•13mo ago
yeah, I'm using use:enhance and PageActions elsewhere, I'm just used to setting up filters client-side 🙂 I'll consider refactoring, thanks!
b1mind
b1mind•13mo ago
You can still do some client side by hooking into the enhance too, I really need to finish my example. I had one but its prior to migration and use:enhance so I'm just writing it manually xD Optimistic UI So you have the client filter that does what it does shows instantly feedback, but meanwhile the server hit happens and returns the real data. either nothing changes for user, or error/revert happens the way you setup https://kit.svelte.dev/docs/form-actions#progressive-enhancement-applyaction Oh funny so in the action redirect is just a goto() haha
Jochem
Jochem•13mo ago
it's not really a clientside filter, it's just the setup for the filter and then rerunning the server side load with the new searchParams. The client never gets more data than the initial page (I'm too old-school to send a whole buttload of data and have the client filter it, it's much slower in my experience with optimized queries and a decent server)
b1mind
b1mind•13mo ago
ah ok heh also load will always run before $page stores I think just a heads up abusing $page store >.>;; its handy af just can get you hung if you are not aware.
Jochem
Jochem•13mo ago
how so?
b1mind
b1mind•13mo ago
Probably just me being silly but I've used it in cases where the $page was not updated with the info I needed when I was running it.
Jochem
Jochem•13mo ago
ah, ok 🙂 I'm only using it one way, from load down
b1mind
b1mind•13mo ago
oh one is when I'm doing page transitions with a {#key} block xD gotta use that load data that might be the main one xD