Kevin Powell - Community•12mo ago

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•12mo 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•12mo 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•12mo ago

https://kit.svelte.dev/docs/load#page-data

SvelteKit docs

Loading data • SvelteKit documentation

b1mind•12mo 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•12mo ago

how so? I'm just using goto

b1mind•12mo 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•12mo 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•12mo ago

Cause its a real form xD Would work without JS or with it (and you could then do fancy client side enhancment)

Jochem•12mo 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•12mo 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•12mo 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•12mo 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•12mo 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•12mo 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•12mo ago

how so?

b1mind•12mo 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•12mo ago

ah, ok 🙂 I'm only using it one way, from load down

b1mind•12mo 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

Gaming

Programming

Update route parameter in SvelteKit