Adobe Xd driven Error, or more importantly — why keeping DRY is very useful

Brian Jones
CodeX
Published in
3 min readSep 24, 2021

DRY — don’t repeat yourself. It's a basic principle of clean code. This week I caught an error in our front-end code, which reinforced the need to keep to this principle. It started a while ago when our designer produced some great designs. Our designer used Adobe xd to pass their designs to us, the dev team, and we took the styles literally.

Photo by Bradley Dunn on Unsplash

Here is the adobe screenshot;

From Adobe Xd properties page

For context — we are porting to a React UI, all very nice and cute. Very component-based. We had a couple of false starts, but now we have a folder of pages and a folder of re-usable components. Each component has its own styling page. We’re using semantic CSS (SCSS driven). For those like me, and the 5 other developers who have committed the same two lines below. ‘Semibold’ isn’t a font, it's a font-weight. See the git change for the before and after.

rad — what was there, green — the replacement

This error was repeated over 100 times. I corrected every damn one by hand. We’re very good at keeping DRY, and SOLID in our back end code. Using React as a front end framework makes that task much seemingly much harder.

Then I had a coffee. Realizing that we had made the same mistake with the regular font weights as well.

Determined not to repeat the mistake that took an hour to fix, I remembered that Scss allows mixins, they’re kinda cool. They allow you to compartmentalize style rules as reusable code. We already had a common base scss style page, but I added in mixins for the semibold font, then searched the codebase to see if we had made the same mistake for other font weights.

Common Scss Page

Then I repeated the process for regular and bold fonts. This still took a long time also. However, I won’t get caught again if we need to change all the fonts. They are all in one place now.-

Summary

Adobe — Please consider doing something for us non-designers who read the specs in xd. Maybe a pseudo-CSS output. We won’t need perfect, we can change it after. Alternatively, make it obvious that semibold is a weight. Even the devs that knew that it was a weight still made the commit for semibold being a font.
When making react components, a stylesheet for each component is a huge mistake if you are reusing common things such as this. Writing things once, then referring to them, using the mixin mechanism makes the process much easier.

Sematic CSS markup is cool, but maintainable code is cooler.

--

--