ljharb / qs

A querystring parser with nesting support

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Top-level array?

spence opened this issue · comments

can qs handle top-level arrays? if not, is this intentional or unsupported? thanks

// expected
Qs.parse("0=0&1=1&2=2")           // [ "0", "1", "2" ]
Qs.parse("[]=0&[]=1&[]=2")        // [ "0", "1", "2" ]
Qs.parse("[0]=0&[1]=1&[2]=2")     // [ "0", "1", "2" ]
Qs.parse(Qs.stringify([0, 1, 2])) // [ "0", "1", "2" ]

// actual
Qs.parse("0=0&1=1&2=2")           // { "0": "0", "1": "1", "2": "2" }
Qs.parse("[]=0&[]=1&[]=2")        // { "0": "0", "1": "1", "2": "2" }
Qs.parse("[0]=0&[1]=1&[2]=2")     // { "0": "0", "1": "1", "2": "2" }
Qs.parse(Qs.stringify([0, 1, 2])) // { "0": "0", "1": "1", "2": "2" }

// inner array works as expected
Qs.parse("a[]=0&a[]=1&a[]=2")     // { "a": [ "0", "1", "2" ] }

As far as I'm aware, that's not a thing query strings support in general. Is that a format you use with a specific framework or ecosystem?

i'm curious if you'd be open to this as a feature -- i'm evaluating qs for a new project where the querystring is passed as an argument to a serverless function. e.g.,:

// > http http://server/sum?[]=1&[]=2&=3

export default function sum(args) { // args = ["1", "2", "3"]
  let nums = zod.coerce.number().array().parse(args);
  return nums.reduce((a, b) => a + b, 0);
}

That seems like a very strange API that will be difficult to work with in a browser :-/ is there a reason that you wouldn't make it:

// > http http://server/sum?_[]=1&_[]=2&_[]=3
export default function sum({ _: args }) { // argument is { _: ["1", "2", "3"] }
  let nums = zod.coerce.number().array().parse(args);
  return nums.reduce((a, b) => a + b, 0);
}

?

Also, I note the combination of []= and = - even if qs (or any library) supported this, I would expect the [1, 2] to be overwritten by the 3.

is there a reason that you wouldn't make it ...

motivation is to simplify / reduce the need for a placeholder. also:

  • mirrors json (e.g., [1, 2, 3] vs { ... }), so it could feel like a natural extension
  • seems like a win when Qs.parse(Qs.stringify(x)) ~= x

Also, I note the combination of []= and =

ah yes, that's a typo.

this sounds like a no to me. i appreciate your thoughts. cheers

yeah, i mean, it's not out of the question to be clear, it's just a lot of complexity to add to a very complex library for what appears to be a very niche use case.

I think you can do it right now with Object.values(qs.parse("[]=0&[]=1&[]=2")) though, if that helps?