If you write it explicitly like that it's fairly useless, yes; but consider something like this:
letx={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.
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.
So, this works
I can hardly think of any situation where this behavior could be intended or even helpful. But, how to prevent this?
If you write it explicitly like that it's fairly useless, yes; but consider something like this:
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.
So I was a bit curious what would happen if an object was defined like
{__proto__: p, x: 1, x: 2}andphad a setter forx, 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.
Can you show the code of the example?