Using querystringparser

[tjconcept]

I noted that you are using the querystring module and not you own querystringparser (when I tried to use this with a nested object), and I'm just curious about why it is so? Is it to keep it a drop-in-replacement of url?

[petkaantonov]

It's because this is supposed to be rewrite of the url module and be integrated into node core

[tjconcept]

Ah, okay, and "they" are not keen on supporting nesting?
Would make sense to increase the performance of the query string parser/formatter as well, wouldn't it?

[petkaantonov]

I suppose if they are not taking drop in replacements for 30x better performance, they are not too keen on changing the APIs of stable modules either :P

[tjconcept]

Sounds plausible.. What a shame - we might see more from io.js.
I guess they could argue that anything that lessens readability is better suited for user land.
Anyway, I don't mind using user land alternatives, but it would be nice to avoid the if (url.query) url.search = '?' + qs.stringify(url.query);-workaround i currently have.
Btw. I am pretty inspired by your work 👍

[petkaantonov]

What's that workaround for?

[tjconcept]

It's for url.format on an object with a query with nested objects.

I use an object of this format to represent state in my web app and on each change I push this state to the history (using url.format). The url.query quite often has some nesting, e.g. in search or filtering.

[petkaantonov]

Actually I could just accept injection of a querystring implementation e.g.

url.qsParser = myQsParser

[tjconcept]

Good enough for me :)

[mikeal]

What a shame - we might see more from io.js.

Are there any API breaks? I can't imagine any reason a 30x perf improvement would be rejected provided it doesn't break or change API :)

[petkaantonov]

Are there any API breaks? I can't imagine any reason a 30x perf improvement would be rejected provided it doesn't break or change API :)

It depends if you consider the implementation of a property as part of the API (data property or getter)

[mikeal]

There's more than one issue swirling around about this so I already made this comment somewhere else but: can't we lazily produce identical output to the current API on stringify/jsonify and iterable? We can eat the perf hit when people touch these edge cases without losing the perf benefits of this approach.