-
Notifications
You must be signed in to change notification settings - Fork 20.6k
isPlainObject() throws TypeError in v2.2.1, but not in v1.11.1 #2982
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
This is a dup of #2968, it should be fixed in master already and in our next patch release. |
Thanks for looking into this. Maybe I should have mentioned that I read and checked #2968 already, as well as its fixes. Unfortunately, they don't fix the issue that I described above. See https://jsfiddle.net/tjmgfjg4/3/ which now uses a copy of the current isPlainObject (from 2.2-stable) I don't mind if you want to merge this with #2968, but please re-open it. Regards, cw |
You're right, it's a different edge case! We can guard against a funny |
I like the idea of checking if |
Hi,
when migrating our code from jQuery 1.11.1 to jQuery 2.2.1, we found a difference between the
jQuery.isPlainObject
implementations in the two versions. This difference also affects other jQuery methods that internally callisPlainObject
, likejQuery.extend
.See https://jsfiddle.net/tjmgfjg4/1/ for a reduced example with jQuery.extend.
The reason seems to be that 3dccf62 removed the
try ... catch
around the following check inisPlainObject
:When
isPlainObject
is called for an object which has aconstructor
property with a non-falsy, non-function value, it now throws aTypeError
("Cannot convert undefined or null to object").I understand that using a property
constructor
with a value other than the original constructor function is somewhat 'unusual' and not best practice. But as far as I can see, this is not prohibited by an Ecmascript spec (up to and including ES2015). I also understand that it is discussable whether such objects should be reported as plain or not. But running into aTypeError
seems quite unexpected.Adding the
try ... catch
back might not be the best way to fix this. But maybe the check could be made more robust by some other mean, e.g. adding another condition (motivated by the concrete error)or by checking whether
obj.constructor
is of type function (motivated by the original intention: check whether the standardconstructor
backlink points toObject
)Please let me know your thoughts about this: regression or valid simplification?
Kind Regards, cw
The text was updated successfully, but these errors were encountered: