The good news was that Emotion and Styled Components have converged on a common API. With a visual testing strategy in place, let's talk about the actual code changes. Our strategy for swapping out Styled Components for Emotion was straightforward: switch component styles then run visual tests. You then review the visual changes to decide if they’re intentional updates or accidental bugs. Every commit, a new snapshot is captured and compared to the previous one to identify visual differences. We have over 2,300 stories! Stories for the Chromatic settings pageĬhromatic captures an image snapshot of every story-as it appears in the browser. We use a component-driven approach to building interfaces and capture component states as stories-for all levels of components, atoms to pages. It automatically checks the UI for visible changes using the cloud.Īs maintainers of Storybook, we practice what we preach. Chromatic's visual testing service offers the same security for UI components. If all tests pass, you can assume that the rewritten function works the same as before. Visual tests to the rescue!įor logic-based code, developers rely on unit tests. We needed a quick and automatic mechanism to compare the appearance of all components to their previous versions. 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. Refactoring CSS is one of the most challenging tasks as a frontend developer.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |