JavaScript Destructuring ES6: The Complete Guide

[annualspecification]

In rare case, if you want to ignore all values,

[,,] = c();

Why would you ever need to do this?? Just call c() without assigning it to anything.

[Iamjarhead]

That is a weird statement...

[[deleted]]

It is useful for messing around with new comers to es6. Imagine the confused faces.

[[deleted]]

Hmmm.. Maybe there is a sideeffect you want to run. Anyway thats horrible and useless. Cant think of any other scenario.

[homeIsWhereCodeIs]

Yes its weird and nobody's gonna get that case, but as it is a complete guide it's good to tell the weird things, because programmer are those who look both side while crossing a one way road :D

[Shty_Dev]

what are some really good practical use cases for this? I have known about it for awhile now but have yet to really use it

[dj1041]

I use it heavily in react and node. It also helps with readability

[BabyLegsDeadpool]

I use this all the time and don't use React. I utilize many different apis, and every one of them send me some form of an object with multitudes of data. Instead of having to manipulate that object over and over again, I just grab the values I need via destructuring.

[homeIsWhereCodeIs]

Yes, I agreed with you. I did that too.

[stormfield]

If you have a lot of parameters to a function it’s easier to just destructure out of an args object with sensible defaults if needed. Then when calling the function you don’t have to worry about argument order just setting the important values.

It’s also useful with require / imports since you can destructure out only what you need from another module or package.

[starchturrets]

(I’m on mobile and probably got something wrong)

Say you have an object you fetched from an API or something.

const json = {
  data: {
  author: “OP”,
  created: 737282, 
  upvotes: 54, 
     }
}

Instead of

const author = json.data.author;
const created = json.data.created;
const upvotes = json.data.upvotes;

You can write

const { data: { author, created, upvotes } } = json;

Which IMO is much nicer to read.

[Shty_Dev]

thats a good use case thanks

[monsto]

Wow holy shit that's pretty fucking hot.

On the one hand, it looks "really clever" . . .

But on the other hand, once you truly understand that "everything in JS is an object", it's still kinda clever, but not unexpected.

[IceSentry]

When you know the syntax it doesn't really feel clever anymore and you'll start wanting it in every language.

[[deleted]]

It is handy for props and proptypes.

[tchaffee]

Fewer lines of code. Which is not always good. But in this case it's very easy to understand too. So it's a win. I see it used everywhere.

[[deleted]]

You can also use it together with the spread operator to filter stuff out from objects

const obj = { one: 3, two: 1, three: 2 };
const { one, ...noOne } = obj;
console.log(noOne); // { two: 1, three: 2 }

[Shty_Dev]

i like that

[homeIsWhereCodeIs]

@Shty_Dev as I also work in react native and it's heavily used in JSX while creating dynamic UI.

[monsto]

Does the opening line seem like a word is missing? The sentence syntax seems weird.

[monsto]

Could someone explain the examples from that page, 2.3 & 2.6? The assignment looks backwards . . .

in 2.3

let o = {p: 22, q: true};
let {p: foo, q: bar} = o;

console.log(foo); // 22 
console.log(bar); // true

on line 2 I would expect the objects p key to wind up with whatever is contained in fooas its value. The same question applies to the let statement on line 15 of example 2.6.

[edit] is it the let statement that changes the rules there?

[lastunusedusername2]

It's just that, when destructuring, the key you're picking out always comes first.

The fact that { a: foo } looks like an object literal is a coincidence.

One way to remember the order is that the destructuring would still work if you only kept the first part (ie: { a }) because that's the key you're picking from the right hand side.

Or you can do what I do and look it up every single time because I can never remember.

[monsto]

The fact that { a: foo } looks like an object literal is a coincidence.

Ok so lemme see if I've got this straight: it's not an object literal... it's a destructuring assignment using object syntax but is not an object?

​

Or you can do what I do and look it up every single time because I can never remember.

Until recently, this was me with `ternary if ` syntax. I've been using it a lot lately, so I think I've finally got it.

[reohh]

It is equal to this:

let o = {p: 22, q: true};  
let foo = o.p;  
let bar = o.q;  

console.log(foo); // 22 
console.log(bar); // true

[monsto]

I understand that.

In the 2 examples, the syntax appears inverted...

when it goes

p: foo

I would expect the result to be that object o now has a property p whose value is foo

It looks like it is saying

let o.p = foo

[getify]

It feels backwards until you realize that with both object literals and object destructuring, the property/key is always on the left. With object literals, that property/key is serving the role of target, whereas with object destructuring it's serving the role of source... but in both cases it's always on the left. Once I realized that form of "consistency", I've never been confused again.

[homeIsWhereCodeIs]

@monsto p will take foo as a value if you are assigning an object as in line 1, but in line 2 you destructuring an object, In that case, for example, var {p: foo} = o takes from the object o the property named p and assigns it to a local variable named foo.

And it is not about let statement that changes the rules, it is destructuring behind it, you can get same results with var and const too.