I'm Stuck on Testing Objects for Properties

if(myObj.hasOwnProperty(checkProp))
return myObj[checkProp];

OK, I’m trying to learn when and why you use certain Javascript “formulas”. I was working on this assignment and didn’t have a clue how to do it. I came to the forum and saw this answer and now understand more about dots and brackets, but I don’t understand when to use which “formula.” I got the if else statement part, knew I needed to use that, but the info in the if statement I never would have gotten on my own.

The myObj.hasOwnProperty makes sense, but the (checkProp) does not, to me. In the return, how does the myObj property get associated with the checkProp and then give you the properties under myObj? Could someone give me their logical train of thought that helped them to know what coding to use?

I’m really struggling with Javascript and want to start understanding how to figure out which “formula” to use when. I looked at this assignment all weekend and just couldn’t even figure out where to start, except I knew I was going to use and if else statement.

3 Likes

Thanks. I appreciate you helping me out. It will probably help a lot of us that struggle with Javascript. HTML and CSS were a breeze, but I feel like I’ve entered an alien world with Javascript.

1 Like

I’m not sure what a formula is. hasOwnProperty is a method that all objects have. A method is a function that is contained in an object. You can’t see hasOwnProperty inside myObj, but it’s there, it’s contained in its parent object, object.prototype.

checkProp is the parameter set in the function, so when the function is invoked with an argument, that argument is referred to as checkProp in the function. The function then calls the function hasOwnProperty on myObj, and feeds checkProp as an argument. Under the hood, hasOwnProperty iterates through the properties of myObj and compares them to the argument which is checkProp. It returns true if myObj contains checkProp, false if it does not.

Normally functions are structured like this : function hasOwnProperty(myObj, checkProp){
… things inside this function …
}
However, since hasOwnProperty is a method, which means that it is a function stored in an object, it is accessed through dot notation. To be clear, myObj, actually contains the function hasOwnProperty as a property in it, and it’s value is the function that hasOwnProperty runs. You just can’t see it, but it’s there. So that’s why hasOwnProperty is invoked this way : myObj.hasOwnProperty(argument);

3 Likes

Thank you P1xt and sethcoch. I’m going to need to spend some time looking at both of you wrote and trying to wrap my head around it. Appreciate your input.

1 Like

Thank you, One of your very similar inputs from a last lesson got me through it. Your hints are usefull in not only solving the problem, but also helps me retain what I’ve learned.

no problem. What I found finally was that I was using dot notation instead of bracket notation to find the value of myObj. It’s important for users at this point of FCC to understand the difference.

Pfew! I thought I was the only one struggling with these concepts. :slight_smile:

But what is the difference???

I wish people would spell things out instead of making cryptic references.

The only time to prefer bracket notation is when the property is more than one word…and I guess when a string is passed into it, as in this “Testing Objects for Properties” exercise.

EDIT: Okay, I see what you’re getting at now…thanks.

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Not sure what you mean…but can you check out my “Epiphany from ‘Testing Objects for Properties’?” Post?

It seems like in this Challenge, bracket notation is preferred because strings get passed into functions along with their quotations marks, thus rendering myObj.checkProp into myObj."gift"???

Whereas myObj[checkProp] conveniently gets rendered into myObj["gift"]…is that why?? Why bracket notation is required here?

Thanks – I get it now. The way the FCC lessons are currently written up, it makes it seem like dot and bracket notations are exactly equal in their “powers” (i.e., in their application).

Seems like a few lessons are missing! I was wondering why there was such redundancy in the language. Turns out, it’s not a redundancy at all!

1 Like

Yeah this reminds me a bit of == versus ===…so I think I’ll just stick to bracket notation. Except when calling properties like lengtharray[length] looks horrible!!

Dot notation can only be used for property names which do not have spaces and that are not referenced as variables.

Hmmm…but as you can see from JS Bracket Notation Safest to Use - Album on Imgur, myObj.12 isn’t possible even though it’s not being “referenced as a variable.”

Well 12 is the property name, after all, in

var testObj = {
  12: "Namath",
  16: "Montana",
  19: "Unitas"
}

Seems a bit “unfair” that 12 is not considered valid for purposes of dot-notation but I’ll just file this under “Treat As If Separated by Spaces” (i.e., use bracket notation – “just the way it is”).

That’s exactly the impression that I had too. It’s definitely not clear.