DEV Community

Put Down the Destructuring Hammer

Derek N. Davis on February 18, 2021

Destructuring is one of JavaScript's most handy features. Once I wrapped my head around the odd-looking syntax, I was a big fan of what it can do. ...

Read full post

Dor Shinar • Feb 18 '21

I'm sorry, that's a straw man argument.
You hand picked bad examples of destructuring, and made the case that using plain old dot notation is superior.
There are a lot of cases where destructuring makes for much simpler code, of the top of my head I can pull out React functional components' props:

const A = ({a, b, c}) => ...

I believe most people will agree that using props.a|b|c all over makes the code more verbose and not easier to understand.

Same goes for utility-like objects, where each property does not bare inherent relation to the others.

const { toSnakeCase } = stringUtils;

Regarding ambiguity, your examples are examples where I don't know anyone who would destructure in the first place, but in other cases (like React's useState), destructuring helps you give better, more meaningful names to your objects.

Derek N. Davis • Feb 18 '21

I think we're on the same page. I'm just giving light to the fact that we shouldn't destructure everything just because we can. There are trade offs. I'm not saying it's all bad. I still like destructuring props and other things where it makes sense.

Adam Nathaniel Davis • Feb 19 '21

Well, I'm not trying to be argumentative but... (Ned Stark said that everything before the "but" is BS). As a React dev myself, I very much appreciate and want that props. preface before the props. Why? Because, I often find myself in the middle of a component where there is the "userId that was passed into the component" versus "the userId that we're currently looking at". In those cases, it's extremely helpful to know which was the "top-level" userId (i.e., the one that was passed into the component) versus the one that we're currently evaluating.

Granted, I'm not claiming that this is always the case with props. Perhaps, it's not often the case. But I very much enjoy looking throughout a component and being able to immediately spot the props - as opposed to any other type of variable.

Jack • Feb 19 '21

Maybe it's just me but when I find I'm in a component where I can't tell the difference between props and internal state / computed values, I think my component probably needs a refactor

Ben Sinclair • Apr 21 '21

This isn't a straw man - the title of the post is "put down the destructuring hammer". It's a play on the old, "when all you have is a hammer, every problem looks like a nail".

What they're saying is that destructuring is nice, but not to use it all the time in every situation without thinking about what you're doing, and whether you're going to make things more difficult for someone else to work on down the line.

Adam Nathaniel Davis • Feb 18 '21

I recently wrote an article exploring the same concept (dev.to/bytebodger/why-do-js-devs-h...). JS devs seem to have an aversion to namespacing. Although I destructure often, there are still many times when I purposely choose to use the object without destructuring - because it can make the code far more self-explanatory.

Derek N. Davis • Feb 18 '21

Great minds think alike I guess! "Well, destructuring effectively robs a variable of its context." So true. And you have a great point about the namespacing. That's even more broad than destructuring, but it makes a lot of sense. I had never thought about it.

Junxiao Shi • Feb 19 '21 • Edited

I find destruction handy for supplying a default value to an optional field.

async function resolve({
  hostname,
  type = "A",
}) {
  return doResolve(hostname, type);
}

async function resolve(opts) {
  return doResolve(opts.hostname, opts.type ?? "A");
  // could be worse if ?? is unavailable
}

Aymeric Bouzy • Feb 23 '21

you can even have a "bug" because of destructuring:

const bob = {
  name: "Bob",
  getName() {
    return this.name;
  },
};

bob.getName(); // "Bob"

const { getName } = bob;
getName(); // undefined

Brad Dunn • Feb 24 '21

There's one legitimate case for that when you are able to leverage some of the tree shaking and unused code elimination during bundling - if you set up webpack correctly, for example, you can import individual functions from lodash while still including the whole lodash package in your dependencies, but at bundle time drop all of the unused functions.

Other than this case, I agree that often context is more important - lodash is such a specific example haha

Andreas Iosifelis • Feb 19 '21 • Edited

I love how we can get the extension of a file name like so:

const [, extension] = filename.split('.')

Vesa Piittinen • Feb 22 '21 • Edited

const filename = 'filename.test.js';
const extension = filename.split('.').pop();

Or if you must have destructure:

const [extension] = /[^.]+$/.exec(filename) ?? [];

But whichever solution that actually is able to select the very last part will work.

Joakim Hedlund • Feb 21 '21

I get the feeling this approach won't work well with files such as foo.bar.js. You may want to reverse() after splitting and picking the first entry as extension instead.