urlParsed doesn't support repeated search params

[ntkoopman]

When making a request to /?foo=bar&foo=baz I would expect pageContext.urlParsed.search to return {foo: ['bar', 'baz']} but instead it returns {foo: 'baz'}.

More in general I think just proving a full url (including host) would be nicer, since then it would be possible to use new URL(pageContext.url).searchParams.getAll('foo'). In addition you could use the hostname when routing (e.g. for multi-tenency).

[brillout]

The pageContext.url you provide at you server middleware is left untouched for you to access.

See https://vite-plugin-ssr.com/pageContext#built-in.

[brillout]

When making a request to /?foo=bar&foo=baz I would expect pageContext.urlParsed.search to return {foo: ['bar', 'baz']} but instead it returns {foo: 'baz'}.

This is by design as params are, most often than not, unique. However I'd be up to impelment something like pageContext.urlParsed.searchAll that provides the list of all values.

Closing in the meantime. I'll reopen and implement this once enough people show intereset for it.

[ntkoopman]

This is not really the case when you use checkboxes, as every checkbox will have the same query parameter.

[brillout]

I'd be up to provide all the values, but I'm not sure how to name it.

What's the different between the naming "search parameters" and "query parameters"? I believe it's also often called a third name, but can't remember it right now.

The naming around query params ist just confusing. If someone can shed some light, then I'll implement this ticket.

[redbar0n]

@brillout

TL;DR: They are synonyms. Going with "search params" is the safest bet, since it's the current official spec.

These are all synonyms for the same thing:

• search params
• query params
• request params
• url params
• url query params

How various libs have chosen to call them:

• search params - the name used by React Location, React Router

• query params - the name used by NextJS, and Router5

Disambiguation:

Everything between the ? and until a potential # in the url is called the "search string" or "query string". It may contain one or more "search params".

Format of URL is like: <path>?<search_string>#<fragment>

Source: https://developer.mozilla.org/en-US/docs/Web/API/Location/search

Example:

Inhttps://example.com/?name=Jonathan&age=18 then ?name=Jonathan&age=18 is the search string, whereas name=Jonathan and age=18 are the search params.

Since the official WC3 specification (orig, updated) and browser API's (URLSearchParams calls them the "search string" and "URL.searchParams", I'd say going with "search params" is a safe bet. They were probably renamed some time after inception:

Modern browsers provide URLSearchParams and URL.searchParams to make it easy to parse out the parameters from the querystring. mdn

If you need to disambiguate and steer people away from mistakenly directly using the browser's API's, I would prefix a namespace, instead of creating confusion by renaming it to "query params" or something else.

[brillout]

Thanks for these thorough insights, very helpful.

Luckily I settled with "search", so we're good here.

I actually revamped pageContext.urlParsed; I believe it now satisfy all needs. More infos at https://vite-plugin-ssr.com/pageContext.

To answer OP: update to vps's latest version and new URLSearchParams(pageContext.urlParsed.searchString||'') will do the trick.