Move a few components to es6 with mixin decorator

[rob0rt]

This is a redirection of #2436 to its own branch.

[alitaheri]

awaiting a conclusion on #2437.

[oliviertassinari]

@subjectix I think that we can merge this one.
However, the rebase after v0.14 isn't going to be straightforward if we continue migrating the doc,
and adding descriptions to getDefaultProps.

[alitaheri]

@oliviertassinari No need to worry we'll iteratively merge master with this branch to keep it updated.

[alitaheri]

Please use arrow functions instead of autobind.

[rob0rt]

Instead of the arrow functions I could alternatively just leave react-codemod alone; it automatically puts this bindings in the constructor. Which would you prefer?

[oliviertassinari]

Having a look at https://github.com/callemall/material-ui/pull/1734/files, I would say, let's let react-codemod puts this.

[alitaheri]

I'm sorry but I completely disagree! Doing that makes the components extremely hard to maintain! I had one hell of bad time with leftnav's doc page component. This is not a good pattern. and using arrow would make it look like this:

_foo = () => {
  // ... 
};

It's not so bad, is it?

[oliviertassinari]

@subjectix react-router seems to follow this convention too (https://github.com/rackt/react-router/blob/master/examples/huge-apps/components/GlobalNav.js).
I don't know why they and facebook do so, but I feel like we can trust them.

[rob0rt]

I just updated with a version that leaves react-codemod's this binding alone.

[alitaheri]

I seriously disagree with this binding -_-

This makes maintenance a living hell. please don't go down this path 🙏 🙏

[oliviertassinari]

This makes maintenance a living hell.

I agree with you.
However, I think that there is a good reason why react-router and facebook are following this path.
Any clue?

[alitaheri]

@oliviertassinari I can think of one thing: named functions, they help debugging. but that's not a priority with a library like this! this library changes very fast. Maintainability is far more important that some tiny extra information in the stack trace. I use them with my project and I'm truly happy with them.

[rob0rt]

I personally like the @autobind syntax since I think it's a good middle ground between syntax and maintainability.

es7 stage-1 decorators are still pretty new so I'm not surprised a ton of libraries aren't using them yet, though I have found uses in the wild.

Personally, I use them for my React project (as well as other decorators, unrelated) and I find them to be easy to understand and keep the function declaration syntax consistent.

[rob0rt]

But in the end I will defer to whatever the collaborators decide on.

[alitaheri]

@BobertForever Go on and use @autobind if decorators are accepted then we can party 🎉 🎉. if not. we'll change them back to arrow functions with gallons of tears :D :D
But for now, keep the productivity up 👍 👍

[rob0rt]

Sounds like a plan to me :)

(And I'll join you on the tears, I have so many of these decorators all around my codebase at this point)

[rob0rt]

Just updated the diff back to using the decorator

[alitaheri]

I'm happy with this 👍 Thanks a lot @BobertForever 🎉

@oliviertassinari Please merge if it's ok.

[oliviertassinari]

@BobertForever Thanks for working on this.

[alitaheri]

🎉 🎉 Our first shot at this 👍