Internal querystring parser doesn't support arrays
nathanboktae opened this issue · 5 comments
I noticed the internal default querystring parser doesn't support arrays. I do remember you removed qs as a dependency in 1e5e96b, so I was wondering if you are interested in supporting it before I make a PR. I'm guessing it'd add about 15 lines of code to the internal one.
As an aside, there are more querystring packages on npm than your current one has lines of code, sadly.
For you - would it not make sense to plugin qs?
I suppose it's a bit more difficult in a non CJS/webpack/browserify environment.
The idea here was to keep internal qs as simple as possible. Is there even a standard way of parsing arrays?
would it not make sense to plugin qs?
Yes I know you can provide your own querystring implementation, so I was wondering where you are drawing the line for feature support for your internal qs implementation.
Is there even a standard way of parsing arrays?
foo=a&foo=b should result { foo: ['a', 'b'] }, but I've also seen foo[]=a&foo[]=b, probably because there is no way to specify a single item array with the former.
Hmmm given that, maybe it should be left as-is.
Yeah the more I dig the bigger the mess I see... Is an empty array just not there, foo[]=, or foo= ? or maybe just foo[]? sigh... Lack of standards here hurts.
Well, we have a couple options here, perhaps i should just bring back
the qs module by default and make things easier. This is a router after
all. The other option for you is to just pull in qs to your app.
Sorry that i keep "rejecting" your PR proposals. Just being careful with
how the project evolves. I really apreciate your contributions regardless.
On Tuesday, 10 November 2015, Nathan Black notifications@github.com wrote:
Yeah the more I dig the bigger the mess I see... Is an empty array just
not there, foo[]=, or foo= ? or maybe just foo[]? sigh... Lack of
standards here hurts.—
Reply to this email directly or view it on GitHub
#118 (comment)
.
Sorry that i keep "rejecting" your PR proposals
NP, and honestly this was a question and I convinced myself against it. Query string parsing is totally not standardized, so a simple parser in < 20 lines with the option of providing your own is the best way, which is what cherrytree does now.
Just being careful with how the project evolves
That's the right default reaction. Any addition is ever ongoing maintenance, or a breaking change that requires upfront notice and user pain. I've rejected more PRs to mocha-phantomjs than I've accepted in the last year or so :/