Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Encoding query arrays with name[] convention #185

Closed
mathieutu opened this issue Nov 5, 2023 · 7 comments
Closed

Encoding query arrays with name[] convention #185

mathieutu opened this issue Nov 5, 2023 · 7 comments

Comments

@mathieutu
Copy link

Environment

Node v21.1.0
[email protected]

Reproduction

withQuery('http://ufo.test', { q: ['foo','bar'] })

Describe the bug

When using withQuery with an array, the param is duplicated instead of having the array syntax.
ex:

withQuery('http://ufo.test', { q: ['foo','bar'] } )

Expected: http://ufo.test?q[]=foo&q[]=bar
Actual: http://ufo.test?q=foo&q=bar

Additional context

Thanks for you work!

Logs

No response

@nozomuikuta
Copy link
Member

Potentially duplicate of #41

@mathieutu
Copy link
Author

Indeed. So at least could we add a mention in the doc, or throw/log an error in this case?
I'm using ofetch, I've past an array in query and didn't understand why my Laravel backend had a weird behavior. It's because of ufo not implementing the standard common way to do.

@pi0
Copy link
Member

pi0 commented Nov 6, 2023

As you probably know, this is URL standard behavior to duplicate params with same key name:

const p = new URLSearchParams()
p.append('q', 'foo')
p.append('q', 'bar')
console.log(p.toString()) // q=foo&q=bar

But i agree that it is was another common way to encode array params mainly in PHP world to use []. Ideally i like to allow "q[]" is the key.

URL standard encodes the key as well:

const p = new URLSearchParams()
p.append('q[]', 'foo')
p.append('q[]', 'bar')
console.log(p.toString()) // q%5B%5D=foo&q%5B%5D=bar

For ufo, i think we might think about serializing it as q[]=foo&q[]=bar i have to double check standard docs if not encoding [] in the query key is valid tough (which I'm pretty sure is valid). This is something we could fix/add in ufo.


After this i think documenting array encoding in ofetch would be a nice idea when patch arrives, feel free to open an issue or directly draft PR in ofetch for this ❤️

@pi0 pi0 changed the title Query arrays are not encoded properly Encoding query arrays with name[] convention Nov 6, 2023
@mathieutu
Copy link
Author

mathieutu commented Nov 6, 2023

Actually, it already works with a q[] key, so it should be probably enough. I'll send a pr to ufo and ofetch readmes. (and to be honest, I never wondered about the standard way to do that before 😅)

@pi0
Copy link
Member

pi0 commented Nov 6, 2023

Amazing! Only i think ufo needs encoding change still 😅 (unless laravel already handles decoding in param names)

import { withQuery } from "ufo";

console.log(
  withQuery("/", {
    "q[]": ["foo", "bar"],
  })
);

outputs

/?q%5B%5D=foo&q%5B%5D=bar

@pi0
Copy link
Member

pi0 commented Feb 5, 2024

update: URLSearchParams seems to encode [] in keys too so probably sticking with it to be more compatible with future plans of adopting more natives (#208)

@pi0 pi0 closed this as not planned Won't fix, can't repro, duplicate, stale Feb 5, 2024
@Tofandel
Copy link

Tofandel commented Aug 9, 2024

This is very problematic in nuxt from the backend as there is no distinctions when passing an array with a single key, this results in very unexpected results when there is only 1 element or 2 elements, could we maybe add an option for this?

    useFetch('/api/test', params: { foo: 'bar', bar: ['baz'] }); // foo=bar&bar=baz
    // From the backend
    console.log(getQuery(event));  // { "foo": "bar", "bar": "baz" }
    
    useFetch('/api/test', params: { foo: 'bar', bar: ['baz', 'foo'] }); // foo=bar&bar=baz&bar=foo
    // From the backend
    console.log(getQuery(event));  // { "foo": "bar", "bar": ["baz", "foo"] }

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants