Query params not serializes as expected #3740

Closed
sporto opened this Issue Aug 24, 2013 · 36 comments
@sporto
sporto commented Aug 24, 2013

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
sporto commented Aug 24, 2013

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

@sporto sporto referenced this issue in FineLinePrototyping/angularjs-rails-resource Aug 24, 2013
Open

Serialisation not as expected by Rails #38

@Nitrodist
Contributor

+1

@mustmodify

+1

@ifeltsweet

Please fix this.

@Zohaibaig

+1

@kwoon
kwoon commented Feb 21, 2014

+1

@caitp
Contributor
caitp commented Feb 21, 2014

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
sporto commented Feb 21, 2014

@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
Contributor
caitp commented Feb 21, 2014

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.

@elanperach

+1

@500tech-user

+1

@yonibot
yonibot commented Sep 9, 2014

+1

@nirkaufman

+1

@lgalfaso
Member
lgalfaso commented Sep 9, 2014

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

@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
Contributor

+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
Contributor

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
taelor commented Dec 8, 2014

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
taelor commented Dec 8, 2014

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

@jchatel
jchatel commented Dec 9, 2014

+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

@petebacondarwin petebacondarwin modified the milestone: Backlog, 1.4.x Dec 15, 2014
@danbarua
Contributor

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.

@pkozlowski-opensource pkozlowski-opensource self-assigned this Dec 18, 2014
@caitp
Contributor
caitp commented Dec 18, 2014

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
jchatel commented Dec 18, 2014

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.: #3311 and #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.

@pkozlowski-opensource pkozlowski-opensource added a commit to pkozlowski-opensource/angular.js that referenced this issue Apr 1, 2015
@pkozlowski-opensource pkozlowski-opensource feat($http): support custom params serializers
Closes #3740
Closes #7429
Closes #9224
12f261e
@pkozlowski-opensource pkozlowski-opensource added a commit to pkozlowski-opensource/angular.js that referenced this issue Apr 2, 2015
@pkozlowski-opensource pkozlowski-opensource feat($http): support custom params serializers
Closes #3740
Closes #7429
Closes #9224
292c757
@odedniv
odedniv commented Jul 5, 2015

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';
}]);
@netman92 netman92 added a commit to netman92/angular.js that referenced this issue Aug 8, 2015
@pkozlowski-opensource @netman92 pkozlowski-opensource + netman92 feat($http): support custom params serializers
Closes #3740
Closes #7429
Closes #9224
Closes #11461
91cf48f
@armanforghani

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

@xuwupeng2000

+1

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment