Giters

GoogleChromeLabs / webpack-libs-optimizations

Using a library in your webpack project? Here’s how to optimize it

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Should we mention `babel-react-optimize`?

kurtextrem opened this issue · comments

commented

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: facebook/create-react-app#553 (comment)

commented

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? :–)

commented

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.

commented

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.