You might need to determine if an object holds a particular property.
Let's say we have a user object. Optionally the email property can be set. I...
For further actions, you may consider blocking this person and/or reporting abuse
Note that starting with ES2022
Object.prototype.hasOwnProperty()
has been "replaced" withObject.hasOwn()
:Object.hasOwn() - JavaScript | MDN
The Object.hasOwn() static method returns true if the specified object has the indicated property as its own property. If the property is inherited, or does not exist, the method returns false.
Quote:
"JavaScript does not protect the property name
hasOwnProperty
; an object that has a property with this name may return incorrect resultsβ¦The recommended way to overcome this problem is to instead use
Object.hasOwn()
(in browsers that support it). Other alternatives include using an externalhasOwnProperty
".For more details see: TC39 Proposal: Accessible
Object.prototype.hasOwnProperty()
There even is an ESLint rule concerning this
no-prototype-builtins
.To some degree this demonstrates that it is dangerous in JavaScript to think of objects as objects in the class-based object-oriented sense because there is no guarantee that every JavaScript object will have a prototype and therefore that
Object
will be in its prototype chain.Oh nice addition Peer,
Missed that one on TC39, but great to see this adoption as it makes total sense.
You could also do
if(userOne["email"])
but I would not recommend to check like thisuserOne.email !== undefined
because what if the object in general does not exist?means:
When userOne does not exist e.g. you forget to pass parameter in a function call, then
(undefined).email !== undefined
will evaluate not into false or true=> skip if condition
A fix for that though would be to check if the object exist and if not, assign an empty object to it.
options = options ?? {}
if (options.switch !== undefined)
can now resolve in true or false.As suggested in another comment optional chaining will work just fine here.
Yeah that's why I mentioned the undefined check to be the least favorite one of all.
It get's messy and very prone to cause headaches later on.
I really like ensuring JavaScript safety by JavaScript built-in environment (browser, node..) and what the language has to offer itself. No typescript, no build systems...
I think it doesn't really make code complex not is it hard to achieve. With good discipline and attention I think the developer would have even more control on his code.
Thanks for the article
Sometimes we tend to overcomplicate for no reason.
Plain JavaScript can handle a lot of things for us that actually might even work quicker.
You could also check for the existence of the property name in
Object.keys(obj)
. Again, this only checks the objects own propertiesAh yes, indeed another way of checking for own properties.
Great article! I'll add into this using Optional chaining. It helps narrowing down your code when using TypeScript a ton. Of course, also very useful while writing plain JavaScript too.
Optional changing can be a real life-saver when it comes to determining this indeed.
You have a typo in your conclusion where you say
but you mean "in".
Thanks Ben!
Noticed and adjusted it π
Great man.. want more tips like this from you..
Awesome!
Let's do some more hands-on tips πͺ
Thanks for the snippets. These are perfect additions to my coding toolbox.
Awesome Imia π