Jaydeep Pipaliya

Posted on Apr 9

Can You Guess the Result of This JavaScript Code?

#javascript #programming #quiz #discuss

What is the output of below javascript code ?

Top comments (16)

Jon Randy 🎖️ • Apr 10 • Edited

Yes, c - every subsequent property definition is overwriting the previous one.

Luke Inglis • Apr 10

For a little extra context here on why the overwriting occurs. Object keys can only be one of two things a String or a Symbol. All three definitions above result in a the String '1' being used for the key since anything that isn't a Symbol is coerced into a String.

𒎏Wii 🏳️‍⚧️ • Apr 10

Here's another one: Can you figure out what this expression will return?

Array.prototype.findLastIndex.call({length: 20}, value => value==undefined)

It should be obvious what it does at face value, but can you tell for sure if that actually works without running it? ;)

Jai Bhati • Apr 10

return the index of the first element where there is no value present (undefined) in reverse order like 19..18..17...

Jai Bhati • Apr 10

This is why its the last index but internally the traversal is done from the reverse order

Rohit • Apr 10

Eckehard • Apr 10 • Edited

So, this works

let x = {1: "a", 1: "b", 1: "c"}
console.log (x) -> { 1: 'c' }

I can hardly think of any situation where this behavior could be intended or even helpful. But, how to prevent this?

𒎏Wii 🏳️‍⚧️ • Apr 10

If you write it explicitly like that it's fairly useless, yes; but consider something like this:

let x = { foo: "fallback", ...defaults, bar: "override" }

Putting explicit properties on either side of the spread lets you establish whether the spread or the direct assignment takes precedence. Extending this behaviour to two explicit assignments to the same key only makes sense.

That being said, any linter worth its salt should detect code like that, because setting a variable twice explicitly is almost always unwanted, although I am not 100% sure if this is always superfluous.

𒎏Wii 🏳️‍⚧️ • Apr 10

So I was a bit curious what would happen if an object was defined like {__proto__: p, x: 1, x: 2} and p had a setter for x, so I tested it real quick.

Turns out, even in that case, which is the only possible way I could think of to introduce side effects inside an object literal, JavaScript ignores the setter on the prototype and creates a data property on the new instance (which then also shadows the inherited accessor property from the prototype).

So no, as far as I can tell, a double assignment in an object literal will literally never have any semantic meaning.

Yolvan G. Zambrano • May 12

Can you show the code of the example?

Stephen Firecrow Silvernight • Apr 10 • Edited

I think it would be c but lets make it a little more interesting

const arrOrObj = [];
arrOrObj[1] = "a"
arrOrObj["1"] = "b"

// What is this?
console.log(arrOrObj["1"]);

Array indexe of 1 auto populates an array of length 2, does the string "1" go in the index or the object key value store?

𒎏Wii 🏳️‍⚧️ • Apr 10

Did you mean to leave x unused, or is that a mistake in your example?

Either way, after line 3 the array [undefined, "b"] so whether you index it with ["1"] or with [x], the result is going to be b

Stephen Firecrow Silvernight • Apr 10

Your right that x was unused, I've removed that. That's true, the reason I posted this is because arrays are slightly different from object bracket access.

but yes it's b

MD. JAHID HOSSAIN • Apr 10

yes, result will be "c".

In JavaScript, object keys are internally converted to strings. In this case, all three property keys are essentially considered as the string "1". Since the last assignment to obj["1"] is "c", that value will be printed, resulting in "c" as the output.