One upon a time, there was a significant upgrade to the Javascript language called ES6/ES2015. It introduced many different new features. One of th...
For further actions, you may consider blocking this person and/or reporting abuse
You have a bug in your code.
The second line will set fruitsAndVegetables to the count of the new length of the array. Not the reference to the array itself
Thanks for noting!
Hmmm, now you are mutating fruit array.
Are you sure you were not trying to do something like
I don't believe there is a neat little 1 liner to do the equivalent without wrapping 'carrot' in a temp array.
I feel the same way...the new syntax is much more compact.
I still use the "old way" about as much as the new way ... because I'm old? Actually, no, I think I am used to manipulating things with methods not operators. But JavaScript is changing, pipeline, bind operators for example.
Fun things to know: spread does exist in other languages but in most cases it doesn't do as much as it does in JavaScript.
It is an addition, syntactic sugar, old things still work. It has its pros and cons.
Everything is syntax, valid or no it's still parsed and lexed to build an AST, so "part of the syntax" seems broad. If it isn't an operator perhaps it's more like a comma or semi token? But those describe white space, spread does a heck of a lot more, I'm not sure what it is now... Sorry to nitpick 😅
This isn't correct, parameters always have to be named, none of the popular engines support this.
Thanks for noting
I was about to say the same. What he wrote is just wrong syntax. I may work if it is compiled to regular function, but in a native implementation it will not work.
It is just old, not wrong, still runs in Chrome. Bad syntax would be non backward compatible breaking change.
It is not just old, is wrong. You can of course declare such function because the permissive nature of javascript, but if you try to run it you are going to get an error because arguments is an undefined variable. You can see it yourself in the (hopefully) attached screenshot.
But you don't have to trust me, is on the spec: developer.mozilla.org/en-US/docs/W...
I had a misunderstanding here, thanks for linking the documentation
No problem. JS is a tricky language (sometimes 😄).
As soon as I wake up tomorrow, I'm gonna check this out in some console, I ask because 'assign' doesn't copy getters and setters, having used that for years and years, it came as a bit of a shock.
I, too, was curious about this, so I decided to run some code in the console! It looks like both spread and
assign
will copy "normal" getters, but they will not copy getters that are explicitly marked as non-enumerable usingObject.defineProperty
orReflect.defineProperty
:However, when an object is an instance of a class that defines a getter, the getter is on the object's prototype and so it doesn't show up during enumeration and therefore doesn't get copied with object spread/
assign
:I would assume this behavior to be consistent with setters.
Noted, updated the example.
Do setters and getters and discriptors get coppied?
Added it as a warning, thanks.