Manually checking every components' visual appearance during the refactor would take more time than implementing the actual changes. Components often override the styles for their child components and global styling has unpredictable impacts on UI elements. The cascading nature of CSS means that minor changes in one file can have unintended consequences without warnings or feedback. But simulating these states for 500+ components is hard to eyeball and extremely tedious. It has multiple variations, which all look slightly different.Īs you refactor the CSS, you have to ensure that each variant appears the same as before. Take, for example, this Cardinal component. The styling of a component changes based on the UI and the application state. CSS refactors lead to accidental bugsĬSS is contextual. The team felt that Emotion offered better performance and features for our use case so we decided to refactor everything else to use Emotion.ĥ41 components across five codebases needed to be updated! To lead the migration, we enlisted Mateusz Burzyński, one of the maintainers of Emotion. ![]() We considered porting Storybook to use Styled Components, but that would lead to an unnecessary upgrade cycle for users and open the door for dependency headaches. The Storybook ecosystem - Emotion (left) and Styled Components (right) Maintaining parity between two versions of the same components slowed us down and added more work, so it was time to invest in a unified styling strategy. ![]() Over the past year, the Storybook team launched many features that also introduced new UI patterns. Chromatic, which came later, used Styled Components, as did the design system and all subsequent sites. For historical reasons, Storybook and Chromatic were built with different styling libraries. Read on to learn about the migration and our test setup. We couldn't have done it without automated tests. ![]() That meant refactoring 541 components across five codebases and not breaking any UI along the way. Last quarter we migrated from Styled Components to Emotion across all our codebases. Moreover, dealing with global styles, overrides, pseudo-states and browser quirks makes the job extra complicated. You need to improve the code without altering the look and feel of the UI.īut it's tricky to catch visual changes as you refactor an entire production codebase across multiple repos. Put your email in the box to hear when I write new things.Refactoring CSS is one of the most challenging tasks as a frontend developer. I'm an open sourcer and ride-or-die React fan. But because is now the officially recommended approach for all React projects (the vanilla option isn't even mentioned on the Readme anymore), I suspect thousands of developers using it who would be better served by plain ol' emotion.Īnd finally: a huge thank you to the Emotion team for all their exceptional work and contributions to the open-source community. ![]() Vanilla emotion was undoubtedly getting flooded with GitHub issues by frustrated developers hitting against subtle limitations of its design. And there's no complicated Babel plugin or config file to set up. There's no need to modify your markup/JSX - as it should be! You only need to install a single module ( yarn add emotion). You sprinkle in your styles using the standard className attribute. You can powerfully compose classes in powerful ways with the cx utility (the Emotion equivalent of Jed Watson's classnames). It's easy to define style classes - both inline or in separate files. The essay below has modified to address some of his points.Įmotion is my favorite CSS-in-JS library. A maintainer of Emotion published a very thoughtful response to a version of this post! I encourage you to check that out here.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |