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.

You know instead of:

  const getObj = (id, store) => { return { id } }

You could write:

  const getObj = (id, store) =>  ({ id })

I'm pretty sure that's a good illustration of my point.

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.

The deep matching gets too cluttered, but the simple case I find to be quite readable and useful:

http://es6-features.org/#ObjectMatchingShorthandNotation

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 agree that object destructuring makes the code far less readable. Array destructuring however is easy for anyone to grok.

It depends I think.

For example, in my opinion

    const Header = ({ children, iconName, iconSize, title }) => { ... };

is more readable than

    const Header = (props) => { ... };

    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.

  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.

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.

And suddenly I get it. Very nice example.

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.