2

I was suggested to change this:

if ( typeof user.account.products !== 'undefined') {}

to this:

if (user.account && user.account.hasOwnProperty('products'))

In second example user.account was added as an extra measure of defence, and it is valid. Now the other part got me curious.

I understand what it does, but still cant wrap my head which one to use.

2
  • The second example gives another layer of checking, which is good. Your first example will throw an error if user.account doesn't exist. Commented May 10, 2017 at 13:24
  • Glad that other answer was deleted, because it was WAY off. Because it had votes that it was useful, just want to clarify that (typeof a === undefined) would tell you that the result of typeof is undefined, which would be a major problem. The correct comparison for typeof IS (typeof a === 'undefined'). Now, see below for the answer to your question of which is better. Commented May 10, 2017 at 13:31

3 Answers 3

2

The first check means

if ( typeof user.account.products !== 'undefined') {
   // i will execute if products property is defined on user.account
   // even is null or 0
}

The second check means (simplified)

if (user.account.hasOwnProperty('products')) {
   // i will execute if user.account has a property of "products" even if products property is undefined/null/0 
   // and also i wont be executed if user.account is inherited from something has its own 
   // "products" property but not defined on user.account's prototype (inherited property).

}  

There is also a third option that you haven't mentioned is this

if ('products' in user.account) {
  // i will execute if user.account has a property of
  // "products" even if products property is undefined/null/0
}
Sign up to request clarification or add additional context in comments.

1 Comment

I like the third option
1

When a property doesn't exist and you try to get its type or value, you get undefined. If you convert undefined to a Boolean (which is what an if/then statement does with the expression supplied as the condition), you get false because certain values are truthy and others are falsey.

So this is an explicit way of testing for not undefined:

if ( typeof user.account.products !== 'undefined') {}

And, this is an implicit way of doing the same thing:

if (user.account.products)

Now your line:

if (user.account && user.account.hasOwnProperty('products'))

Is more specific than either of these because not only does it test to see if user.account exists, but it also tests to see if that object has its own products property. If it is that property you intend to use and there is a chance the user.account may not exist or that it may, but may not have products as a property, then this is the best way to test for it.

But, there are still other ways to do this kind of testing. This:

if(account in user && products in user.account)

Checks to see if the respective properties exist in their host object without regard to whether the properties are inherited or not.

But, in the end, if it is the products property you care about, all you really need is:

if(products in user.account);

This test will fail if products isn't there or it user.account isn't valid.

It all depends on how granular you want to test.

3 Comments

If you check using hasOwnProperty won't it report false if products exists in the prototype, but not on the object itself?
@evolutionxbox Yes, it will. But as I said in my answer, "it also tests to see if that object has its own products property."
Sure. (ps, my comment was a question, not a challenge)
0

If I get your question correctly, you are asking why using:

user.account.hasOwnProperty('products')

instead of:

user.account.products !== undefined

In that case, the two options are valid. With that saying, the new option (hasOwnProperty) is more elegant- Instead of assuming that the property exists, and then check if it is defined, you are asking if the object has this property.

Comments

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.