I solved the record collection challenge using,
(!collection.tracks)
as one of my conditions.
**NOTE
(!collection[prop]) also works
Is there any reason that I should have used
(!collection.hasOwnProperty(“tracks”))
instead?
It seems simpler to me to not use hasOwnProperty. Will this hurt me down the road?
I didn’t know and search on google, and end up with this
that they compare this model in this flavour
hasOwnProperty with for..in
like
for ( var key in obj )
...obj.hasOwnProperty(key...
and with Object.keys
keys = Object.keys(obj);
for (i = 0, l = keys.length; i < l; i++)
...
This answer might solve “down the road”
.
.
.
When u do for..in u transverse all enumerable properties, that is object’s own and inherited properties
and then u use in body of for..in, hasOwnProperty to check does that enumerable property is own
With Object.keys u transverse just own enumerable properties
Found that Object.keys are 50%+ faster then for..in
Yes! As nameToReachPeople mentioned you’ll want to use hasOwnProperty when you iterate over object. The for…in loop iterates over all the enumerable properties of an object. That includes the properties you define and all the properties belonging to the object through the prototype chain. Using hasOwnProperty filters out these inherited properties so you act on only properties you defined.
Objects are great because they carry universal browser support and can can be used in your client-side code. If you want to branch out, ES6 introduced new data structures that have additional features, including iteration methods.
With Map(), you can iterate over keys and values with for (let [key, value] of map) and map.forEach(). These are safe to use on server-side code like when you’re coding in Node but don’t have the complete browser support for client-side code. (You can scroll down to the bottom on MDN pages to see details on browser support).