Bracket notation vs. Dot notation

Tell us what’s happening:
I have a doubt about why I have to use bracket notation, instead of dot notation when I return the value of the property that was found. Why can I not say:
‘return obj.checkProp’ ?
Thanks!

  **Your code so far**

function checkObj(obj, checkProp) {
// Only change code below this line

if(obj.hasOwnProperty(checkProp)) {

  return obj[checkProp];
}
return "Not Found";
// Only change code above this line
}
  **Your browser information:**

User Agent is: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/90.0.4430.93 Safari/537.36.

Challenge: Testing Objects for Properties

Link to the challenge:

because dot notation uses exactly what you have written, bracket notation evaluates what’s between the brackets, so it’s the only way to work with variables

1 Like

I understand that I have to use bracket notation with variables.
However, in this particular exercise, it is specified that ‘checkProp’ is a property.
Does the same apply? Because the way freecodecamp explains it in the antecedent lectures I really cant catch the difference when it comes to accessing properties of an object with either dot or bracket notation.

it still apply because checkProp is a variable that hold a string, and the property is the string in the variable, not the variable name
the object does not have a variable named literally checkProp (in that case you could use dot notation)

1 Like

Another way to look at it. The variable checkProp is dynamic in this circumstance. It’s string value is unknown until the function runs. Because of the dynamic nature, you have to use bracket notation or . hasOwnProperty.

Dot notation does not work when the property names are dynamic.

Can you give me an example of what a dynamic variable would be? Vs. lets say one that isn’t? Thank you!

Yes. I will show example of a dynamic variable vs a static variable.

First we have one global object that we will access using different patterns.

Data:

let obj1 = {
  prop1: 'test',
  prop2: 'some value'
}

Accessing a property using a static value:

console.log(obj1.prop2)
// 'some value'

// or 

console.log(obj1['prop2'])
// 'some value'

This is static because you have literally hard coded the property name. prop2 is seen as a string value “prop2” and cannot change in this instance.

Notice ‘prop2’ here is a String, not a variable.

If i were to make this dynamic, it gets more tricky, and special requirements are required in order to be fancy.

function fancyPants (dynamicArgument) {
  console.log(obj1[dynamicArgument])
}

fancyPants('prop1') // passing in strings

fancyPants('prop2') // passing in strings

This is dynamic because I could pass the fancyPants function literally any string i want. If that property didn’t exist in the function it would error, but it’s dynamic in nature as i can enter whatever i want into that function.

Also notice how if we tried the static example with bracket notation, it would error out unless you enter it as a string. It seems bracket notation is designed for more flexibility with dynamic ability.

console.log(obj1[prop2])
// Uncaught ReferenceError: prop2 is not defined
1 Like

Great! Thanks a lot!

I can see why it’s confusing but notice how on the right hand side checkProp is supplied as a parameter to the function checkObj, and on the left hand side checkProp is put inside a pair of parentheses.

Try to look at the entire picture and understand that the challenge isn’t saying that the tested object has a property that’s literally checkProp e.g.

{someProp: someValue, checkProp: someOtherValue}

but saying that the tested object has a property that’s passed via the parameter checkProp.

Also note that a parameter is a variable.

Like @ilenia said:

  • You can’t use dot notation because JavaScript rules insist on using whatever follows the dot AS IS to look for the property, i.e. JS does NOT consider the possibility that it could represent some other value.

  • But when you use bracket notation, JS rules do acknowledge the abovementioned possibility and evaluate what’s inside the brackets to its literal value, then look for the property using that value.

Okay, great, got it. Thanks a lot!

This topic was automatically closed 182 days after the last reply. New replies are no longer allowed.