4 ms·

While I'm a big believer in most of the ES6 changes (arrow functions! let/const! classes! generators!), I am not a big fan of many of the new destructuring feat

by zelias 10y ago

While I'm a big believer in most of the ES6 changes (arrow functions! let/const! classes! generators!), I am not a big fan of many of the new destructuring features. They can actually make your code less approachable if you don't already know what's going on.

fryan 10y ago
I agree that object destructuring makes the code far less readable. Array destructuring however is easy for anyone to grok.
- ggregoire 10y ago
  It depends I think. For example, in my opinion const Header = ({ children, iconName, iconSize, title }) => { ... }; is more readable than const Header = (props) => { ... };
  - fryan 10y ago
    const Header = ({ children, iconName, iconSize, title }) => { ... }; Once you get used to the destructuring parameter idiom, sure. It also conveys more information. But that statement is overloaded in that it makes use of implicit object shortcuts which has a bit of a learning curve for longtime ES5 users. const Header = ({ children: children, iconName: iconName, iconSize: iconSize, title: title }) => { ... }; When object destructuring is nested it can be confusing and more verbose.
    - lhnz 10y ago
      function thisIsBad ({ someKey: renamedSomeKey, someOtherKey: renamedSomeOtherKey = 'otherDefaultValue', meta: { innerMetaKey = 'someInnerMetaKeyValue', otherInnerMetaKey, ...remainingMeta } } = { someKey: 'defaultValue', someOtherKey: SOME_CONSTANT, meta: {} }) { // ... return { someKey: renamedSomeKey } } My favourite messed up part of the syntax is the way the `:` character is used to describe either the default value of a property or a way of renaming the name of a property internally (depending on whether it is to the left or right of an `=`). And also, the way you can destructure the inside of an object, and automatically lose the original value. For example `meta` is not accessible within the function defined above. This is syntax which can simplify your code if you apply it carefully, but will ruin your code if you over-use it.
      - fryan 10y ago
        I had to debug code like that the other day. Before you debug it you have to mentally grok wtf is going on. What a mess.
  - deleted 10y ago
    [deleted]
  - Semiapies 10y ago
    And suddenly I get it. Very nice example.
Roboprog 10y ago
The deep matching gets too cluttered, but the simple case I find to be quite readable and useful: http://es6-features.org/#ObjectMatchingShorthandNotation http://es6-features.org/#ObjectMatchingShorthandNotation
marcoperaza 10y ago
I agree about the object destructuring. The examples set off loud alarm bells in my head. Very cute and very unreadable. Like others are saying, though, the array destructuring seems fine.
BinaryIdiot 10y ago
I completely agree and it's nice to see someone else with the same thoughts because I've found a ton of opposition regarding this. I hate the destructuring syntax. While I understand how it works now I felt like it took me too long and feels very non-obvious so I try to avoid it in my code unless absolutely impossible to avoid. I don't find it intuitive especially for newer developers.
i__believe 10y ago
Exactly, and this is a big problem where I work. I believe code should be readable, even by those with only cursory knowledge of the language. Object shortcuts is also a problem I think. For example, I had a method like this: const getObj = (id, store) => { return { id: id name: store.something.name }; }; The linter gave an error on it because I used {id: id}. It was like the linter was trying to make my code harder to read. I think es6 in the wrong hands quickly falls prey to the problems of ruby/scala where it can become incredibly terse and hard to parse unless you are used to the author's particular style.
- gidan 10y ago
  You know instead of: const getObj = (id, store) => { return { id } } You could write: const getObj = (id, store) => ({ id })
  - i__believe 10y ago
    I'm pretty sure that's a good illustration of my point.
    - dwaltrip 10y ago
      This is a matter of personal preference. I find `return` to be quite distracting and annoying for a small function that spans part of a line, while you and some others may prefer the explicitness of the `return` keyword. I would agree that nested destructuring should be used quite cautiously. Code legibility is incredibly important to the success of any serious project.

by zelias 10y ago

fryan 10y ago

I agree that object destructuring makes the code far less readable. Array destructuring however is easy for anyone to grok.

ggregoire 10y ago
It depends I think. For example, in my opinion const Header = ({ children, iconName, iconSize, title }) => { ... }; is more readable than const Header = (props) => { ... };
- fryan 10y ago
  const Header = ({ children, iconName, iconSize, title }) => { ... }; Once you get used to the destructuring parameter idiom, sure. It also conveys more information. But that statement is overloaded in that it makes use of implicit object shortcuts which has a bit of a learning curve for longtime ES5 users. const Header = ({ children: children, iconName: iconName, iconSize: iconSize, title: title }) => { ... }; When object destructuring is nested it can be confusing and more verbose.
  - lhnz 10y ago
    function thisIsBad ({ someKey: renamedSomeKey, someOtherKey: renamedSomeOtherKey = 'otherDefaultValue', meta: { innerMetaKey = 'someInnerMetaKeyValue', otherInnerMetaKey, ...remainingMeta } } = { someKey: 'defaultValue', someOtherKey: SOME_CONSTANT, meta: {} }) { // ... return { someKey: renamedSomeKey } } My favourite messed up part of the syntax is the way the `:` character is used to describe either the default value of a property or a way of renaming the name of a property internally (depending on whether it is to the left or right of an `=`). And also, the way you can destructure the inside of an object, and automatically lose the original value. For example `meta` is not accessible within the function defined above. This is syntax which can simplify your code if you apply it carefully, but will ruin your code if you over-use it.
    - fryan 10y ago
      I had to debug code like that the other day. Before you debug it you have to mentally grok wtf is going on. What a mess.
- deleted 10y ago
  [deleted]
- Semiapies 10y ago
  And suddenly I get it. Very nice example.

Roboprog 10y ago

The deep matching gets too cluttered, but the simple case I find to be quite readable and useful: http://es6-features.org/#ObjectMatchingShorthandNotation http://es6-features.org/#ObjectMatchingShorthandNotation

marcoperaza 10y ago

I agree about the object destructuring. The examples set off loud alarm bells in my head. Very cute and very unreadable. Like others are saying, though, the array destructuring seems fine.

BinaryIdiot 10y ago

I completely agree and it's nice to see someone else with the same thoughts because I've found a ton of opposition regarding this. I hate the destructuring syntax. While I understand how it works now I felt like it took me too long and feels very non-obvious so I try to avoid it in my code unless absolutely impossible to avoid. I don't find it intuitive especially for newer developers.

i__believe 10y ago

Exactly, and this is a big problem where I work. I believe code should be readable, even by those with only cursory knowledge of the language. Object shortcuts is also a problem I think. For example, I had a method like this: const getObj = (id, store) => { return { id: id name: store.something.name }; }; The linter gave an error on it because I used {id: id}. It was like the linter was trying to make my code harder to read. I think es6 in the wrong hands quickly falls prey to the problems of ruby/scala where it can become incredibly terse and hard to parse unless you are used to the author's particular style.

gidan 10y ago
You know instead of: const getObj = (id, store) => { return { id } } You could write: const getObj = (id, store) => ({ id })
- i__believe 10y ago
  I'm pretty sure that's a good illustration of my point.
  - dwaltrip 10y ago
    This is a matter of personal preference. I find `return` to be quite distracting and annoying for a small function that spans part of a line, while you and some others may prefer the explicitness of the `return` keyword. I would agree that nested destructuring should be used quite cautiously. Code legibility is incredibly important to the success of any serious project.