Earlier quoted context omitted.
the core use case is var { foo } = pony I agree this is kind of silly in isolation, but more often than not, its used like this: var { foo, bar, baz } = pony which is honestly not that hard to read, and is much better than var foo = pony.foo; var bar = pony.bar; var baz = pony.baz; which is very useful when you're referencing properties of pony a lot. Since you're going to see destructuring used like var { foo, bar,…
I wish they'd let you return stuff this way, like: return {a, b, c} = foo;
ES6 Overview in Bullet Points
11–20 of 50 posts
Re: ES6 Overview in Bullet Points
#12Great writeup. I welcome most of the additions, but I somehow cannot get behind things like: var {foo} = pony is equivalent to var foo = pony.foo var {foo: baz} = pony is equivalent to var baz = pony.foo I am not sure why, but most languages get into a state where they seem to encourage non-readable code. What was wrong with 'var baz = pony.foo' to start with?
I find it most useful for import statements: import {Button, Text} from 'react-native'; and in function declarations: function f({foo, bar})
Re: ES6 Overview in Bullet Points
#13This is awesome, but can I just say foo/bar/baz drives me nuts. How about `{outerProperty: {innerProperty: 'innerValue'}}` ? That just seems so much easier to follow to me, especially in these deep-nested destructuring examples. But anyway, seriously, this is awesome. The author is responsible for a large part of my ES6 knowledge.
If we never see them again it will be too soon.
Re: ES6 Overview in Bullet Points
#14Can anybody explain why "let" variables are hoisted to the start of block given this Temporal Dead Zone exists? Is it an artifact of modern JS runtimes?
And given the TDZ what practical benefit does knowing that the variable is technically hoisted provide?
Re: ES6 Overview in Bullet Points
#15Re: ES6 Overview in Bullet Points
#16> Temporal Dead Zone - Attempts to access or assign to foo within the TDZ (before the let foo statement is reached) result in an error Can anybody explain why "let" variables are hoisted to the start of block given this Temporal Dead Zone exists? Is it an artifact of modern JS runtimes? And given the TDZ what practical benefit does knowing that the variable is technically hoisted provide?
Re: ES6 Overview in Bullet Points
#17> Temporal Dead Zone - Attempts to access or assign to foo within the TDZ (before the let foo statement is reached) result in an error Can anybody explain why "let" variables are hoisted to the start of block given this Temporal Dead Zone exists? Is it an artifact of modern JS runtimes? And given the TDZ what practical benefit does knowing that the variable is technically hoisted provide?
[deleted]
Re: ES6 Overview in Bullet Points
#18Looking good and informative, but to be honest I am really interested in use cases. I think I understand how to use generators but I have no idea where I could use them in real-world scenarios. Same goes for WeakMaps, Proxies... Anyone care to give some examples?
Re: ES6 Overview in Bullet Points
#19JS is a very complicated language - and the language spec in written in a way - that while I am sure is excellent for implementors and compatibility - is pretty much unreadable by language users.
Axel's book is quite authoritative and very readable. You may still go to the spec for finer points - but it sure is 10,000 times easier if you mostly understand the mechanism (and motivations) first.
Re: ES6 Overview in Bullet Points
#20> Temporal Dead Zone - Attempts to access or assign to foo within the TDZ (before the let foo statement is reached) result in an error Can anybody explain why "let" variables are hoisted to the start of block given this Temporal Dead Zone exists? Is it an artifact of modern JS runtimes? And given the TDZ what practical benefit does knowing that the variable is technically hoisted provide?
[deleted]
// line 1
{
// line 2
let x = 5; // line 3
// line 4
}
// line 5
What is the actual end language user difference between saying the scope of x is lines 2-4 but magic (TDZ) makes it unavailable on line 2 vs. saying the scope is from line 3 to 4 with the TDZ being an implementation detail?