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:
constA=({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.
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.
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.
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
I've been a professional C, Perl, PHP and Python developer.
I'm an ex-sysadmin from the late 20th century.
These days I do more Javascript and CSS and whatnot, and promote UX and accessibility.
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.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
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:
I believe most people will agree that using
props.a|b|call 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.
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.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.
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.
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
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.