ES6 JavaScript Destructuring in Depth

I’ve briefly mentioned a few ES6 features (and how to get started with Babel) in the React article series I’ve been writing about, and now I want to focus on the language features themselves. I’ve read a ton about ES6 and ES7 and it’s about time we started discussing ES6 and ES7 features here in Pony Foo.

This article warns about going overboard with ES6 language features. Then we’ll start off the series by discussing about Destructuring in ES6, and when it’s most useful, as well as some of its gotchas and caveats.

A word of caution

When uncertain, chances are you probably should default to ES5 and older syntax instead of adopting ES6 just because you can. By this I don’t mean that using ES6 syntax is a bad idea – quite the opposite, see I’m writing an article about ES6! My concern lies with the fact that when we adopt ES6 features we must do it because they’ll absolutely improve our code quality, and not just because of the “cool factor” – whatever that may be.

The approach I’ve been taking thus far is to write things in plain ES5, and then adding ES6 sugar on top where it’d genuinely improve my code. I presume over time I’ll be able to more quickly identify scenarios where a ES6 feature may be worth using over ES5, but when getting started it might be a good idea not to go overboard too soon. Instead, carefully analyze what would fit your code best first, and be mindful of adopting ES6.

This way, you’ll learn to use the new features in your favor, rather than just learning the syntax.

Onto the cool stuff now!

Destructuring

This is easily one of the features I’ve been using the most. It’s also one of the simplest. It binds properties to as many variables as you need and it works with both Arrays and Objects.

That’s roughly how you can use destructuring. What is destructuring good for?

Use Cases for Destructuring

There are many situations where destructuring comes in handy. Here’s some of the most common ones. Whenever you have a method that returns an object, destructuring makes it much terser to interact with.

A similar use case but in the opposite direction is being able to define default options when you have a method with a bunch of options that need default values. This is particularly interesting as an alternative to named parameters in other languages like Python and C#.

A great fit for destructuring are things like regular expressions, where you would just love to name parameters without having to resort to index numbers. Here’s an example parsing a URL with a random RegExpI got on StackOverflow.

Special Case: import Statements

Even though import statements don’t follow destructuring rules, they behave a bit similarly. This is probably the “destructuring-like” use case I find myself using the most, even though it’s not actually destructuring. Whenever you’re writing module import statements, you can pull just what you need from a module’s public API. An example using contra:

The main reason for these limitations is that the import statement brings in a binding, and not a reference or a value. This is an important differentiation that we’ll explore more in depth in a future article about ES6 modules.

I’ll keep posting about ES6 & ES7 features every day, so make sure to subscribe if you want to know more!

* How about we visit string interpolation tomorrow?**We’ll leave arrow functions for monday!

The 'such_dynamic' example is a bit of a stretch. Why would you define an object via object literal, just to pull out a dynamic key value and then immediately discard the object? It seems more likely that the object would be pre-existing (in outer scope or function argument), in which case var foo = obj[key] is sufficient.

However, I am unsure why are you working directly on an object in one example and you are assigning an object to a variable and then operating on a variable in another. the ES5 should be done in the following way to make the comparison more representative: