Learn how one team started with a little project that became a huge one to introduce a dark mode that included refactoring, creating aliases, and more.
Join the DZone community and get the full member experience. Like many companies, we have a Hack Week at Sentry. In 2017, we coded an app which blared entrance music for anyone who stepped foot in our office. In 2019, we encouraged folks to be nice on the Internet. Noble causes, sure, but for this year’s Hack Week I was determined to advance a cause near and dear to my cold British heart: dark mode. Little did I know that what started as a minor hack week project would become a major lift that included pantone colors, hex codes, and all sorts of variables. But first things first. If you head on over to User Settings > Theme you can toggle Dark Mode on. We also added an option where you can switch it based on your default system theme: Given its recent popularity, you might believe dark mode is a fad. But from a design perspective, dark mode is exceptionally useful. That’s because a big part of design is about building relationships between colors. And so implementing dark mode essentially forced everyone on the team to think long, hard, and consistently about our front-end design components. In short, dark mode helped our design system not only look good, but make sense. We organized the work into three buckets: As I began spelunking around our codebase, I found all sorts of color inconsistencies. Things like scattered hex codes and one-off variables such as blueLightest or offWhite being used in all sorts of curious ways. This meant that whenever an engineer wanted to actually to build something, they were forced to think way too long and much too hard about which color they should use. Here’s an example: I want to add a border to a component. Okay, cool. Which variables can I use? Lemme see. I like gray, so let’s use gray. Simple enough, right? Well, there are eighteen grays — not to mention its border variables and hex codes. Which one should I use? Why is the design I’m looking at using a new border color? Where in my life did everything go wrong? No engineer should be forced to answer these questions, and so we went about cleaning up all this junk. To kick things off I made a map of every variable that uses React components. This map was nothing more than a spreadsheet (gross), but it did serve an important purpose: I now knew which deprecated color variables should be replaced. This spreadsheet would help us make a lot of small pull requests where we could change yellowLightest into a new variable called yellow400. Also, by making lots of small pull requests for each variable, we could also limit regressions. Thankfully, most of these variables were stored in one place, as we had been pretty strict about storing them in the theme.tsx file we imported into our React components. Within those components, we applied those styles to emotion, our css plugin. That sounds like a lot — and it is — but emotion is well worth the overhead when building complex apps, as it allows us to isolate our CSS all in a single component like Dropdown so we don’t have to worry about those styles bleeding into other files or pages. Here’s an example of a component that uses emotion: To remove a color like offwhite2, I needed to search across both our codebases and find all the React components that used that particular variable. Only then could I replace it with something more sensible.
