Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP
Browse files

Fix #10466. jQuery.param() should treat object-wrapped primitives as …

…primitives.
  • Loading branch information...
commit 166b9d252a025009413eee1584dc364996dcb1c2 1 parent 6c2a501
@rwaldron rwaldron authored dmethvin committed
Showing with 14 additions and 1 deletion.
  1. +1 −1  src/ajax.js
  2. +13 −0 test/unit/ajax.js
View
2  src/ajax.js
@@ -818,7 +818,7 @@ function buildParams( prefix, obj, traditional, add ) {
}
});
- } else if ( !traditional && obj != null && typeof obj === "object" ) {
+ } else if ( !traditional && jQuery.isPlainObject( obj ) ) {
// Serialize object item.
for ( var name in obj ) {
buildParams( prefix + "[" + name + "]", obj[ name ], traditional, add );
View
13 test/unit/ajax.js
@@ -1031,6 +1031,19 @@ test("jQuery.param()", function() {
equal( jQuery.param( params, false ), "test%5Blength%5D=3&test%5Bfoo%5D=bar", "Sub-object with a length property" );
});
+test("jQuery.param() Constructed prop values", function() {
+ expect(3);
+
+ var params = {"test": new String("foo") };
+ equal( jQuery.param( params, false ), "test=foo", "Do not mistake new String() for a plain object" );
+
+ params = {"test": new Number(5) };
+ equal( jQuery.param( params, false ), "test=5", "Do not mistake new Number() for a plain object" );
+
+ params = {"test": new Date() };
+ ok( jQuery.param( params, false ), "(Non empty string returned) Do not mistake new Date() for a plain object" );
+});
+
test("synchronous request", function() {
expect(1);
ok( /^{ "data"/.test( jQuery.ajax({url: url("data/json_obj.js"), dataType: "text", async: false}).responseText ), "check returned text" );

11 comments on commit 166b9d2

@rkatic

jQuery.isPlainObject is unnecessary here - use the faster jQuery.type( obj ) === "object".

Btw.:
Few lines up, there is typeof v === "object" || jQuery.isArray(v) that can be simplified to typeof v === "object".

Also, if really wonted, the isPlainObject can be avoided in .param too, by replacing a.jquery && !jQuery.isPlainObject( a ) with a.jquery && !hasOwn.call( a, "jquery" ), but this would require hasOwn = Object.prototype.toString on the top - so probably not too beneficial considering that isPlainObject is called only once here.

If you want I can make a pull req.

@dmethvin
Owner

@rkatic, I doubt this would yield any measurable performance improvement in real code, given how seldom this is called. Would you be interested in taking on a larger project for 1.8? These micro-optimizations often are more bother to change than they are worth, we need to be focusing on big gains.

@rkatic

Yea, the last one is certainly an over-optimization, but I pointed it now in case something like that will be needed...
Other two, however, was more for correctness...

Would you be interested in taking on a larger project for 1.8?

Do you have something in particular in mind?
I have intention to try to contribute to jQuery in next months anyway.

@rwaldron
Collaborator

My previous comment's test was backwards, strike that.

@rwaldron
Collaborator

So, jQuery.type(foo) will definitely work fine, but I'm not sure it's worth it? http://jsperf.com/type-vs-isplainobject

@rwaldron
Collaborator

After making the change, byte counter reports:

jQuery Size - compared to last make
  248549     (+4) jquery.js
   93704     (+2) jquery.min.js
   33275      (-) jquery.min.js.gz
@rkatic

It's more about correctness. Consider:

function Record(name, id) {
  this.id = id;
  this.name = name;
}

$.param({"boo" : new Record("foo", 666) });

Why to make this unnecessarily invalid?

Also, an more honest perf would probably be http://jsperf.com/type-vs-isplainobject/2.

@rwaldron
Collaborator

How is that a "more honest perf"??? Because you said so? All you've done is create more noise.

This is the BEST argument given:

It's more about correctness. Consider:

function Record(name, id) {
  this.id = id;
  this.name = name;
}


$.param({"boo" : new Record("foo", 666) });

Why to make this unnecessarily invalid?

Why didn't you lead with that argument instead of nitpicking some half-cocked performance micro-optimization?

@rkatic

This is not the first time that we do not agree on writing perfs, even if I am simply taking in consideration different types... but at the end the ideal perf is probably something in the middle: making more probable types more frequent, but not ignoring others too.

@rwaldron
Collaborator

If you want to account for other types, do so in separate tests - it hardly makes sense to cram 3 different operations into each test.

@rkatic

Maybe that would be even better, but I am not in the mood to make N tests for something like this...

Please sign in to comment.
Something went wrong with that request. Please try again.