🚀 5 Advanced ES6 Features Every JavaScript Developer Should Master

Destructuring is great! Your scenario above is just a result of poor coding, not a problem with destructuring itself. You can destructure to named variables too:

const box = { width: 30, height: 40 }
const {width: boxWidth, height: boxHeight} = box

console.log(boxWidth)  // 30
console.log(boxHeight)  // 40

It's just a tool, and sometimes it's the right one for the job, and sometimes it isn't. Sometimes destructuring is less readable than simply accessing object properties directly. It's certainly the most readable way to swap two vars that I know of:

let a=1, b=2;
[a, b] = [b, a]

console.log(a)  // 2
console.log(b)  // 1

I'm a little confused by your width/height example in 1. If the first dev had done:

    const {width, height} = box

Then width and height couldn't be overwritten. Block scoping might have made new width and height variables but only in a lexical scope, not affecting the previous code unless the new dev wrapped the original code into the new scope. That just sounds like a poor way of constructing a function that has become way too complex and is trying to do too much at once.

It would depend where the code was located, but constant dereferences with box.XYZ are not optimal and might harm performance in a loop.

they put their code in between where Box is defined and above where the Box vars were used, suddenly Box's dimensions break and no one knows why.

I've been trying to figure out how it's even possible to do this with destructuring and the only thing I could come up with is this:

const alpha = { a: 'a', b: 'b' };
const numeric = { a: '1', b: '2' };

var {a,b} = alpha;

// lots of code :see_no_evil:

var {a,b} = numeric;

console.log(a,b); // 1 2

If that's how your scenario happened then it's hardly a compelling argument against destructuring; but instead an argument for implementing linters and proper code review 😅
I haven't used var in years and certainly never in code where destructuring was also supported. Using either let or const in both the destructuring statements results in an error; and in general I'd always recommend using const. Introducing mutable (or global!!!) variables into your code increases the risk of bugs.

Thanks for your long comment @ravavyr ! To be fair, I agree with you and I will say that in my future articles I will improve my examples and try to explain more in depth when it is a good option to use it or not.

I like to use destructuring but as @jonrandy said below, it must be done in the right places, it is just a tool that you have to use in the right place and in the right way.

About the arrow functions, I tend to agree. I like to use the old function() definitions almost everywhere but arrow functions are useful in some places.

In general I think I need to write a second part of this article going in depth with every point. I tried to make it simple and general so beginners can read and then they can keep trying and exploring, discovering the specific cases, but probably I should note these little details there.

For future reference for anyone reading the article, make sure to check this comments' thread, it is pretty useful!

Point 1 is not the fault of destructuring. There's a plethora of bugs like this, if you dont use something like typescript for type safety. Besides that, ALWAYS use const while destructuring.

Its also worth noting that you can assign a new name to the variable while destructuring:

const bed = { width: 180, height: 40 }
const { width: bedWidth, height: bedHeight } = bed
console.log(bedWidth, bedHeight)

Ps. Just realized you can shorten that advice to: ALWAYS use const.

I never had such problems with destruction. Renaming variables upon collision is completely natural.

Anyway, in case I need to use multiple times, I'd definitely assign it to 2 separate variables, which is basically destruction+renaming at the end under the hood. It's not just more performant but it can be efficiently minified while property access cannot, and the same is true for destruction.

const boxWidth = Box.width
const bedWidth = Bed.width

...
Now, Box was added to the code first so the dev just destructured it and used width and height as variables about 50 lines lower in the code, cool, no problem.

50 lines lower I would think is a problem itself and without looking into the source it sounds like there is room for improvement. Declare variables as near as possible to usage and when possible with const.

A year later a support request came in, another dev had to add Bed to the code and they thought destructuring was great too, they put their code in between where Box is defined and above where the Box vars were used, suddenly Box's dimensions break and no one knows why. Original dev looks at their lines and goes "everything looks fine". New dev looks at their code and says "everything looks fine"....until finally someone else looks at the whole thing and goes "You @#$!%"...

A simple walk through would have shown the problem, either with the debugger or with console log, but in the first place I would blame the IDE that is not telling you or are you using a notepad.

As always you must know you tools and use them.

In my opinion object destructure didn't build to solve the problem you've mentioned. To solve that I recommended to use Typescript.

You got a good point. Appreciate the comment

Nicely pointed out. This is valuable feedback. I will definitely think twice next time, before I go all arrow function. Never looked at it like you said: easier to spot when scanning through code.

Thanks, fixing it!

There is also a rest operator when destructing arrays which is sometimes useful. (Forgive me if this formats badly, I'm on mobile)

const nums = [1, 2, 3, 4, 5]

const [first, second, ...rest] = nums

// 1
console.log(first)

// 2
console.log(second)

// [3, 4, 5]
console.log(rest)

Thanks a lot for the comment!