With styled-components into the future
Preprocessing is dead, long live preprocessing!
This is a CFP for ReactiveConf 2017's open call for Lightning talks. If you'd like to see this talk become a reality, please
(If you're searching for the star button on your phone; unfortunately you'll need to request the desktop site
styled-components chose to go with a runtime-only setup to support create-react-app and similar environments. Now that it's taken the React world by storm, what if we enhanced it a little bit at build-time? How optimised can we make it?
What you can expect to see
In styled-components we're constrained to create components with their styles attached to it. This way styles aren't only scoped to a component, they're inseperably bound to it. This constraint gives us a breeding ground for a lot of optimisations that can be performed!
While we previously performed all of our tagged template string magic at runtime, how much of that logic can we move to the build time to avoid unnecessary work on the client? And since some CSS code will never change, can we avoid processing it repeatedly when components update?
In version 3, our big focus will be on how to make styled-components even faster with the help of Babel and Webpack.
CSS-in-JS started as a departure from traditional CSS preprocessors, but in the next version of styled-components we'll be able to revive CSS preprocessing in a new form. But this time, totally integrated with the component-based structure of modern React apps!
About the author
Hiya, I'm @_philpl! I recently started at Formidable Labs in London, and I've been working on styled-components as a Core-Contributor since January. I'm also co-organising the monthly(-ish) Reactivate London meetup.