Query params not serializes as expected

[sporto]

Angular serializes query strings in a particular way that many backend frameworks (including Rails) don't understand. jQuery param on the other hand has been the standard for this for years.

Example 1

var params = {
    arr: [1,2,3]
}

Angular serializes to

?arr=1&arr=2&arr=3

Jquery.param serializes to

arr%5B%5D=1&arr%5B%5D=2&arr%5B%5D=3 

// which is equivalent to
// arr[]=1&arr[]=2&arr[]=3 

Example 2

var params = {
    obj: {
        foo: 1          
    }
}

Angular serializes to:

obj=%7B%22foo%22:1%7D

// equivalent to
// obj={"foo":1}

jQuery.param serializes to

obj%5Bfoo%5D=1 

// which is eq to 
// obj[foo]=1 

There are several closed issues related to this, but this seems to be a common problem, jquery.param looks likes the expected behaviour.

#1363
#3121
#1640

Some of the conversation on these issues seems to imply that this has been done, but I tested this using Angular 1.2 with the same results as before.

Please lets consider making Angular serialization equivalent to jQuery.param

Thanks

[sporto]

This PR #3696 might fix this, will test it later

[Nitrodist]

+1

[mustmodify]

+1

[ifeltsweet]

Please fix this.

[PanfilovDenis]

+1

[tanguyantoine]

+1

[Zohaibaig]

+1

[kwoon]

+1

[caitp]

This is silly. If you know you're dealing with a backend which understands that style of query, just append "[]" to the param name. There's nothing in any of the RFCs regarding URI construction or parsing which makes any statement about a special meaning of "[]". This feels like a wontfix, really.

[pkozlowski-opensource]

@caitp this one is coming back over and over again so at one point I was thinking of abstracting this requests params serialization (and probably parsing) part into a service and thus allow people to swap implementation to match their backend. This should be rather simple to do.

Adding [] is definitively and option, just a bit of pain when you've got your object ready.

[sporto]

@caitp I don't see how this is a silly request, serialization is a basic building block that many libraries build on top. Many time you are high in an abstraction that uses the Angular serialization underneath. So what you are proposing is not a viable option.

Also appending [] only deals with array serialization. jQuery params also makes object serialization different, see above.

Probably asking just to change this completly is an unreasonable request as people using Angular already have crafted their backend for the current way of doing things. But at least Angular should make it very easy to just swap strategies, so it uses that way across the board.

[caitp]

Maybe the jQuery foundation should attend some IETF meetings and turn their quirk into an actual thing ;) I don't think it's a very good idea to do this just for the benefit of a handful of backends. What Angular is doing right now seems to be what is the expected behaviour.

Now, someone comes up with a configurable way to do this which works well, then that's one thing, but I just don't see this as being a very good thing to force on people.

[ilyagelman]

+1 please fix.
The workaround for now is to use $.param and pass it as a part of the url string.

$http.get(page + '/?' + $.param(params))

But this is an ugly solution, which also depends on jQuery.

[elanper]

+1

[ghost]

+1

[yonibot]

+1

[nirkaufman]

+1

[lgalfaso]

I think it should be possible to write a small library that adds a global interceptor to $http and converts the parameters into another format. This was discussed at #7423 and the consensus was that the current serialization works well for most people and that the external module would be the solution for the cases it does not

[timothyjlaurent]

Thanks @ilyagelman!

[goncalvesjoao]

+1
I can't be the only one that can't change the server's code the meet angular's pickiness so, do any of you guys know a workaround this? Even if it's an ugly one...

[gabrielmaldi]

+1

ASP.NET Web API recognizes either:

bar.baz=abc

or

bar[baz]=abc

It would be very convenient if Angular supported this out of the box.

[gabrielmaldi]

Here's how I'm handling it right now:

https://gist.github.com/gabrielmaldi/5453d87402db5a56c1a5

It seems very long because I included uri.js. But the key parts are queryStringParam.js (adapted from jQuery.param) and httpInterceptor.js.

Maybe it helps someone.

[taelor]

I really wish there was something that could be done for all the Rails/Grape developers who are used to dealing with $.params from jquery, but are trying to move to an angular-only front-end client. I think there enough people effected by this that it would make for a stellar option if we could configure our apps to turn on this style of serialization for GET requests.

+1

[pkozlowski-opensource]

@taelor I know this is a pain and we are going to provide an elegant solution for this in the near future. It is in the works.

[taelor]

@pkozlowski-opensource thanks for the super quick reply, its very reassuring!

[jchatel]

+1

As long as the "elegant" solution doesn't come in the form of "2.X sorry we don't give a shit about 1.x", this would be fine.

But... 1.5 years this is open, super annoying and still not fixed, no one assigned, so I would not hold my breath

[danbarua]

As long as the "elegant" solution doesn't come in the form of "2.X sorry we don't give a shit about 1.x", this would be fine.

👍

[pkozlowski-opensource]

A solution will be part of 1.4: http://angularjs.blogspot.fr/2014/12/planning-angular-14.html

@danbarua @jchatel I'm afraid that those snarky comments are not helpful not appreciated... If you want to contribute please comment on the actual technical solution you would propose.

[caitp]

Lets just implement jQuery param serializing, it will make people happy, I guess. We can even add a new "legacy" parameter to the http config to use jQuery's legacy serialization option, just to make the API less confusing for everyone.

[pkozlowski-opensource]

@caitp I'm on it. There is slightly more to it as we need to make sure that people can write tests easily. Going to share a gist with a proposed solution over the weekend.

But yes, I'm working on it and it will be part of 1.4.

[jchatel]

I was just paraphrasing how 2.0 was announced, at least that's how I (and many others) took it.

I think there was plenty of comments already mentioning the solution: jQuery param serialisation and +1 didn't have much effect in the last 1.5 year it seemed.

[pkozlowski-opensource]

For anyone interested in this issue here is the very first draft of a proposed solution for 1.4: https://gist.github.com/pkozlowski-opensource/5a57d28ccfeacaba7661 - if you care about it being solved properly please comment in the gist or in this issue directly.

Unfortunately we can't simply implement jQuery's param logic by default as:

• it would be a breaking change (and a painful one, especially for backends like Java that understand the current serialization schema)
• it wouldn't solve other issues opened for the same area (ex.: Custom URI encoding makes it hard to mock $http requests #3311 and Passing a string that contains a semi-colon doesn't properly get encoded #9224 that my proposal addresses).

Very open to all the constructive comments, let's get it fixed as well as we can in 1.4.

[odedniv]

After reading through this long thread, I still didn't get a solution. Here is a simple one:

module.run(['$http', '$httpParamSerializerJQLike', function($http, $httpParamSerializerJQLike) {
  $http.defaults.paramSerializer = $httpParamSerializerJQLike;
}]);

[pkozlowski-opensource]

(Slightly) simpler (?) / shorter way of doing the same:

module.config(['$httpProvider', function($httpProvider) {
    $httpProvider.defaults.paramSerializer = '$httpParamSerializerJQLike';
}]);

[armanforghani]

@pkozlowski-opensource
$httpProvider.defaults.paramSerializer = '$httpParamSerializerJQLike'; does not work using Angular 1.4.6.

[xuwupeng2000]

+1