Shopify removes duplicate query parameters in embedded apps

[ryanolf]

Issue summary

Embedded admin apps receive a bunch of extra query parameters from shopify that don't appear in the URL bar. It seems that in manipulating the query parameters passed into the embedded app, duplicate parameters are removed, even though they are generally well supported by the URLSearchParams Web API and are one way to represent lists of values.

After initial load I can add duplicate parameters and they work as expected, but they are not maintained upon a true (non-remix) navigation.

Expected behavior

Duplicate query parameters passed in the browser URL should be maintained and accessible in the app.

Actual behavior

Only one of a the duplicate parameter values is kept.

[lizkenyon]

Hi there 👋

Could you help me to better understand your use case for duplicate query params? What feature or value are your trying to provide? Knowing this information will best help us determine the correct solution and prioritization.

[ryanolf]

Thanks for the reply, Liz. I like to use duplicate query parameters to track checkbox state, e.g. in my `IndexFilters`. Using multiple keys with different values mirrors the way form data is encoded. The `URLSearchParams` API provides reasonable ergonomics for tracking lists in this way (via getAll, append, and the iterator methods). There are, of course, workarounds, but there are some semantic differences (e.g. parameter not present versus empty value could have different meanings) and you have to think about how to encode your list (JSON strings, CSV, etc). I've changed to using single key with a comma separated list of selected values for my use case and it's fine. But repeated keys is perfectly valid, and in fact it works fine if such are set in remix and remix internal navigation is used. My expectation as a developer was that the query parameters I set and that appear in the URL will be accessible in my app, and I don't see a good reason it should be any different. Likely in your code that adds the additional search parameters, you're composing the new search parameters as an object that includes the existing search parameters as an object. Converting `URLSearchParams` to an object is lossy. A more robust way to handle them is to keep them as `URLSearchParams` and manipulate them using the methods, or equivalently handle them as a list of [key, value], converting as necessary via `.entries()` or the constructor.

…

On Thu, Mar 20, 2025 at 2:20 PM Liz Kenyon ***@***.***> wrote: Hi there 👋 Could you help me to better understand your use case for duplicate query params? What feature or value are your trying to provide? Knowing this information will best help us determine the correct solution and prioritization. — Reply to this email directly, view it on GitHub <#2243 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAJSBSQ6ZGKKHEBTHJIQGZL2VLFBJAVCNFSM6AAAAABZM4326GVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDONBQGYYTSMRUG4> . You are receiving this because you authored the thread.Message ID: ***@***.***> [image: lizkenyon]*lizkenyon* left a comment (Shopify/shopify-app-js#2243) <#2243 (comment)> Hi there 👋 Could you help me to better understand your use case for duplicate query params? What feature or value are your trying to provide? Knowing this information will best help us determine the correct solution and prioritization. — Reply to this email directly, view it on GitHub <#2243 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAJSBSQ6ZGKKHEBTHJIQGZL2VLFBJAVCNFSM6AAAAABZM4326GVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDONBQGYYTSMRUG4> . You are receiving this because you authored the thread.Message ID: ***@***.***>