.hasOwnProperty("tracks") vs .tracks

1

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?

2

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

1 Like
3

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.

Map
Set

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).

1 Like