JavaScript Property Access: Dot Notation Vs. Brackets

JavaScript property access: dot notation vs. brackets?

(Sourced from here.)

Square bracket notation allows the use of characters that can't be used with dot notation:

var foo = myForm.foo[]; // incorrect syntax
var foo = myForm["foo[]"]; // correct syntax

including non-ASCII (UTF-8) characters, as in myForm["ダ"] (more examples).

Secondly, square bracket notation is useful when dealing with
property names which vary in a predictable way:

for (var i = 0; i < 10; i++) {
someFunction(myForm["myControlNumber" + i]);
}

Roundup:

  • Dot notation is faster to write and clearer to read.
  • Square bracket notation allows access to properties containing
    special characters and selection of
    properties using variables

Another example of characters that can't be used with dot notation is property names that themselves contain a dot.

For example a json response could contain a property called bar.Baz.

var foo = myResponse.bar.Baz; // incorrect syntax
var foo = myResponse["bar.Baz"]; // correct syntax

Difference between using bracket (`[]`) and dot (`.`) notation

Accessing members with . is called dot notation. Accessing them with [] is called bracket notation.

The dot notation only works with property names which are valid identifier names [spec], so basically any name that would also be a valid variable name (a valid identifier, see also What characters are valid for JavaScript variable names?) and any reserved keyword [spec].

Bracket notation expects an expression which evaluates to a string (or can be coerced to a string), so you can use any character sequence as property name. There are no limits to what a string can contain.

Examples:

obj.foo;  // valid
obj.else // valid, reserved keywords are valid identifier names
obj.42 // invalid, identifier names cannot start with numbers
obj.3foo // invalid, ""
obj.foo-bar // invalid, `-` is not allowed in identifier names

obj[42] // valid, 42 will be coerced to "42"
obj["--"] // valid, any character sequence is allowed
obj[bar] // valid, will evaluate the variable `bar` and
// use its value as property name

Use bracket notation:

  • When the property name is contained in a variable, e.g. obj[foo].
  • The property name contains characters not permitted in identifiers, e.g. starts with a digit, or contains a space or dash (-), e.g. obj["my property"].

Use dot notation: In all other situations.

There is a caveat though regarding reserved keywords. While the specification permits to use them as property names and with the dot notation, not all browsers or tools respect this (notably older IE versions). So the best solution in my opinion is to avoid using reserved keywords for property names or use bracket notation if you cannot.


†: That's also the reason why you can only use bracket notation to access array elements. Identifiers cannot start with digits, and hence cannot consist only of digits.

Javascript Dot Notation vs Bracket Notation

for(var key in sunny){
console.log(sunny.key)
}

sunny.key in bracket notation is equivalent to sunny["key"]. It is searching for a property name "key" which is not there in your object.Hence returning undefined always.

key here is actually variable , not a string to extract the value of a property.

See : https://codeburst.io/javascript-quickie-dot-notation-vs-bracket-notation-333641c0f781

Access numeric properties of an object using dot notation

Your question seems to be about why we can’t access array and array-like elements using the dot notation like this:

const v = a.0;

It’s described in the ECMAScript specification:

The dot notation is explained by the following syntactic conversion:

MemberExpression . IdentifierName

And identifiers may not start with a digit as described here:


IdentifierName ::

IdentifierStart

IdentifierName IdentifierPart

IdentifierStart ::

UnicodeLetter

$

_

\ UnicodeEscapeSequence


As for the reasoning, having identifier names just being made of digits would have made it difficult to write number literals. An exception could probably have been designed just for array access but that would have made the language more complex and departing from the common C family syntax without any real gain.

difference between dot notation and bracket notation in javascript

When you use dot notation, key means the actual property in the object, which will not be there. So, undefined is returned which is not equal to true.

When you use [] notation you are accessing the property in the object with the name in the variable key. So, that will work.

For example,

var myObj = {
myVar : 1
};

for (var key in myObj) {
console.log(key);
console.log(myObj.key);
console.log(myObj[key]);
}

This will print,

myVar
undefined
1

Because, myObj has no member named key (myObj.key tries to get the member with the name key) and in the next case, myObj has a member named myVar (myObj[key] tries to get the member with the value in key).

Dot Notation

jslint prefers dot notation.

[] Notation

This offers flexibility. You can dynamically access the members with a variable.

JavaScript: Different behavior when using dot-notation vs. bracket-notation

The behavior that you are experiencing is because the undefined property of the Global object, is mutable on any ECMAScript 3 based implementation. (latest Chrome versions are implementing ES5, but this behavior is still present).

Let's examine the second snippet:

var x = window.foo;
window[x] = null;
alert( window.bar === undefined );

The x variable will hold the undefined value, since the foo property does not exist.

By assigning window[x] = null, you are overriding the value of the undefined property:

window[x] = null; // is equivalent to
window['undefined'] = null; // or
window.undefined = null; //

(In your first snippet, when you assign window.x = null, you are creating a property named "x" on the window object.)

Therefore (in your second snippet), the undefined property will hold null, and window.bar will produce undefined:

alert( window.bar === undefined ); // false
alert( undefined === null ); // false

The undefined property was not specified as { ReadOnly } on ECMAScript 3, (along with his friends NaN, Infinity).

This has changed in ECMAScript 5, those properties are described as non-writables.



Related Topics



Leave a reply



Submit