JavaScript: !! vs hasOwnProperty vs 'in' ???

In the past, I've often recommended people avoid the "!!" syntax in JavaScript, when checking to see if an object has an attribute. There are too many dangers with this syntax returning incorrect values.

Yet, I found myself reaching for this syntax, instinctively, because of its specific behavior.

In this episode of WatchMeCode Q&A, you'll find out exactly what these three syntax options do, and why each of them provides value in JavaScript.

[thany]

You can also write:

obj.foo !== undefined

if you don't care about existing attributes that may be undefined.

[igoldny]

I still find my self 99% of the time using bang bang because i do want to check if the value is also truthy.
btw i didn't know you can use "in" outside a loop statement, thnx for the great explanation.

[KelvinWKiger]

Amazing, thank you for sharing your knowledge.

[Qbe_Root]

hasOwnProperty is actually a property of Object.prototype, so you could as well just type obj.hasOwnProperty('foo'). ;-) The only cases where it won’t work are Object.create(null) and objects that redefine hasOwnProperty.

[VipinGoyalvicky]

I learnt new thing from your screencast i.e. !! ( Bang Bang :P), Thanks :)

[joshdavison]

When used in a conditional, is the double bang the same as no bang?
I.E. Is `if ( !!this[CONNECTION_KEY] )` equivalent to `if ( this[CONNECTION_KEY] )`

[caerphoto]

@6:50 shouldn't that be Object.hasOwnProperty.call(f, "foo") ? Otherwise you're calling Object's hasOwnProperty method in the context of Object, not f.

Not that this changes your larger point, of course, just that it might be a bit confusing.

[michaeledmondson]

Pitfall: `!!this[CONNECTION_KEY]` would return `false` if CONNECTION_KEY was zero. Zero could be a valid value, say an array index. (I could not imagine other falsy values -- empty string, null, NaN -- into "valid" values.)

[GeneralYouri]

I have to disagree. I don't see how you wanting to 'check if the property contains a real value' suddenly permits using this type of operator.

Quoting you: "I don't want to just know that my transaction object has a connection sitting at this connection key. I want to know that the object sitting in this attribute is a truthy object. I want to make sure that it is not set to [que listing falsy values]".

But this is not true. You're not actually checking whether it *does not* have an *incorrect* value, but you want to check whether it *does* have a *correct* value. In other words, if you were expecting the property to hold an instance of some constructor 'Connection', then you check `this[CONNECTION_KEY] instanceof Connection`.

Just because that coincidentally happens to produce the same results as using the !! operator, doesn't mean you should use it. Think about what you *truly* want to do in the method, and write directly that. This helps increase the clarity in your code as well. To the average developer, it'll be much more obvious what the line is doing when using something like `this[CONNECTION_KEY] instanceof Connection`, instead of `!!this[CONNECTION_KEY]`.

Note: I used `instanceof` as an example, and obviously there may be alternatives needed depending on what type of value is being checked against. Regardless, there should always be a more direct and clear check than using `!!`.

[DanDart]

I find myself using 'undefined' == typeof x[n] a lot... looks as ugly as -1 !== b.indexOf(c)