Should we mention `babel-react-optimize`?

[kurtextrem]

See here for more details: https://medium.com/doctolib-engineering/improve-react-performance-with-babel-16f1becfaa25 Personally, I'm using babel-plugin-transform-react-pure-class-to-function most of the time. plugin-transform-react-inline-elements is buggy and disabled in create-react-app, same for plugin-transform-react-constant-elements as it hurts TTI - see: https://github.com/facebookincubator/create-react-app/issues/553#issuecomment-359196326

[iamakulov]

So, to sum this up:

babel-react-optimize includes 4 plugins:

• transform-react-inline-elements (buggy)
• transform-react-constant-elements (potentially hurts time to interactive)
• transform-react-remove-prop-types (already recommended)
• transform-react-pure-class-to-function

Recommending transform-react-pure-class-to-function seems like a good idea – it could make the bundle smaller by removing Babel’s class helpers (see babel repl with class vs babel repl with function). We might want to revisit this in a couple of years though when IE (the only major browser not supporting classes) becomes less relevant.

Want to make a PR? :–)

[kurtextrem]

Want to make a PR? :–)

Sure thing! I also just got the idea to, if browserslist target allows, to transform: function Foo(props){return exp} to const Foo=props=>exp

this saves another 11 bytes for single line returns and 2 for multiple statements. I wonder if it's worth it to create a plugin for that case.

[iamakulov]

I wonder if it's worth it to create a plugin for that case.

Might worth it!

Such conversion might break the this/arguments/.bind()/etc references though, so the plugin would need to account for that. In general, applying it seems OK for React components (because they usually don’t rely on this or .bind()) but not OK for an arbitrary function.