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.

[petkaantonov]

Sure you can define a toJSON method that emulates the output that an eagerly parsed url object would give. JSON.stringify implicitly calls it.

[mikeal]

Would we still have iterable issues? I haven't gotten deep enough in to property access guts to know if that will also be an issue but I'm pretty sure that we have a way to emulate it now in ES6.

[petkaantonov]

The getters are currently not enumerable (that is of course trivial to change) but even after changing them to enumerable, they are still on the prototype and not on the object itself which trips up stuff like ._extend.

[jedwards1211]

@petkaantonov

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

Just curious, did it ever get merged into node core?