Ability to imperatively parse the path params, at clientside runtime #1871
Conversation
|
| function routeParams_() { | ||
| const { routes } = router.parse(new URL(location.href)); | ||
| if (routes.length === 0) return {}; | ||
| const match = routes[0][0].exec(location.pathname); |
There was a problem hiding this comment.
This could use a comment as to why this line and the next are routes[0]. It seems like it's only checking the first route? Why is that?
There was a problem hiding this comment.
That's a really good comment. I think if there's multiple ambiguous matching routes it gives them all, we'd probably want the first or the last, I'll need to investigate. The order comes from whatever order they're in generated/manifest.js.
Also I don't love the magic indices after that. I should cast it as a CSRPage type and destructure it instead.
I'll have an update soon.
|
I should probably close this, since the main reason to do this is in support of general-case static prerendering, which we're not doing now or perhaps ever. See #1870. |
Normally, client-side code would get the path params from
$page.params. For pre-rendered pages however, those values are the values as they were at pre-render time, which isn't useful if you're using a single pre-rendered HTML artifact to handle an entire parameterized route with path params which vary at runtime.In such case, you'd want look at the details of the particular request, by inspecting
window.location. This is fine for path and query string, but not currently possible for path params because we don't have the information about its pattern or param names.This simply adds that ability, and should be considered in conjunction with just-now submitted #1870.
Before submitting the PR, please make sure you do the following
Tests
pnpm testand lint the project withpnpm lintandpnpm checkChangesets
pnpx changesetand following the prompts. All changesets should bepatchuntil SvelteKit 1.0