querystring => qs, adds support for nested objects - #1301

Are the [] in the query sent with or without %-encoding?

I recall playing with this yesterday and seeing %-encoding show up once (in Chrome) and it worked just the same.
Attaching some screen shots to illustrate behavior from Chrome, including one where I force %5B and %5D.

chrome

curl

curl -g http://localhost:3000/aloha\?event\=test\&ids\[\]\=1\&ids\[\]\=2

{
  "code": 400,
  "error": "Bad Request",
  "message": "the key (ids[]) is not allowed",
  "validation": {
    "source": "query",
    "keys": ["ids[]"]
  }
}

curl -g http://localhost:3000/aloha\?event\=test\&ids%5B%5D\=1\&ids%5B%5D\=2

{
  "code": 400,
  "error": "Bad Request",
  "message": "the key (ids[]) is not allowed",
  "validation": {
    "source": "query",
    "keys": ["ids[]"]
  }
}

Does this prevent you from using ember.js?

it prevents you from using the rest adapter and forces you to roll your own -- but it doesn't outright deny you the ability to use hapi with emberjs. but it makes it a lot harder to get going.

in general, the key[] naming convention is something i learned about it when playing with rails a few years ago: http://guides.rubyonrails.org/action_controller_overview.html#hash-and-array-parameters

This came up once before. I personally dislike it but would like to hear from others before making a decision. It is easy enough to enable with a plugin that overrides the request member in 'onRequest'.

for the sake of understanding -- is it that convention of using [] that you don't like, the dependency on qs rather than node's core querystring module, or something else?

it's unclear to me at this time how I could pass {"some":{"nested":{"object":12345}}} as a querystring without this change. (aside from extending with onRequest -- I mean with vanilla hapi)

I don't like the [] notation. What's wrong with using an extension? You can just directly change request.query. But I'd like to know what others think.

There's nothing wrong with extending it to serve my purposes, it's your project to take in direction that best suits your team/goals. I personally think it's in hapi's best interest to support these conventions for the sake of wider spread adoption, but given that this is made for walmartlab and you're simply being a hero by sharing it with the OSS community that may be irrelevant -- don't degrade your baby just for me.

It is misleading (to me) though that right now you can submit data via query or payload, and validations exist to check for objects on a querystring, but there is no way to actually send an object via querystring:

~  node
> var q = require('querystring')
undefined
> q.stringify({root:{child:"abracadabra"}})
'root='

First - this is not for Walmart. This is an open source project used by many other company. I get to make the final decisions but that should never be based on my personal taste. This adds a new dependency and while I certainly appreciate the use case, I want to see if others find it useful to make the complexity trade-off worth it (since you can accomplish the same thing with very little hassle per-need). A few +1s and I'll be happy to find a way to accommodate it (maybe with a config flag).

As for being misleading, the quest does get parsed into an object, even if it is flat...

Awesome, thank you sir!

Aside, I didn't mean any insincerity in my hero comment -- I'm genuinely grateful that this project wasn't kept closed source.

This thread has been automatically locked due to inactivity. Please open a new issue for related bugs or questions following the new issue template instructions.