How to Effectively Maintain CSS in a Large Application

In this article, I'll cover one of the ways how CSS maintenance can be achieved. Don't take it as a single right way of doing it, I'm only going to share which approach works for me and is proven to be good scaled and shared between several projects.

Before diving into details let's have a look at this picture and see how several large UI products can be built inside of the single organization. They use custom components and share them between products, to give them the same look and feel and gain performance in development, as problems have to be solved only once and can be reused across products.

You may also like: How to Deal With CSS Issues in IE When You Have No Idea How to Fix Them

What do we have here? For simplicity, we only have one shared library of components and two different applications/products in the organization. We have two shared components as the date component and the scheduler component. Which are designed in a specific way and we would like to give them custom configurable behavior, that's why we even created them.

Currently, in application A only Date component is used and in application B both components are utilized.

What kind of things we can do to make our products looking similar? Of course, styles have to be shared! Every default component has to look the same, colors across products should be also identical. What can we do for that? First of all, I recommend using in any project reset.css , you can find a lot of examples on the internet, that's one of them https://meyerweb.com/eric/tools/css/reset/. After that, we have to define all styles/rules for all components in organisation.(css|less|sass) file. 

 Once it's finished the rest of the components have to contain isolated styles, so it can be reused in different projects and don't affect the behavior of adjusted or parent components. One of the things how to achieve it is to give unique identifiers. I'll give an example of how to do it with LESS:

xxxxxxxxxx

.shared-components.custom-date-component {

  .datepicker__navigation--next {

      &:hover,

      &:focus {

        border-left-color: black;

      }

   }

  .datepicker__navigation--previous {

      &:hover,

      &:focus {

        border-right-color: black;

      }

   }

  ...

}

It is achieved by creating a hierarchy of styles, so that means datepicker_navigation--next will be applied only inside of custom-date-component component. As the component name also prepended with the name of the library, it makes the chance of class duplication close to zero.

To make the navigation by styles fast, it's better to use the same name for the component, file name, and CSS class name.

xxxxxxxxxx

// custom-date-component.js

import './custom-date-component.less';

export const CustomDateComponent = () => <div/>;

xxxxxxxxxx

.custom-date-component {

 ...

}

If you start messing with names, you will be in a situation to do unnecessary navigations to figure out which classname relates to which component. Even if you use some generic styles for components, better keep the same strategy and locate the common classname inside.

xxxxxxxxxx

.custom-date-component {

  .some-shared-class-name;

}

Now let's imagine that you need to add the same Admin page for application A which already exists for application B. By abiding by the same strategy inside of the application by keeping each block in isolated style will make that sharing of components easy.

What to do if Date component in application B has extra styling needed — you keep that override inside of .application-b  class name.

xxxxxxxxxx

.application-b {

 .custom-date-component {

  color: red;

 }

}

In that case all styles from .custom-date-component and on top of that color  is overridden only for application B. Even when Admin page is added to application A styles going to be in shape, as a red color only will be applied for application B. If you need to do it for Admin page, not application related, then you do override of .admin-page  not .application-b. 

Note: One common mistake which I always see, keep all such overrides related to a component, not higher to hierarchy, not lower. If you do this:

.admin-page {

 .custom-date-component {

  color: red;

 }

}

Keep it inside of Admin Page Component, not application B project globally, or some parent component. Otherwise, you start losing control of what comes from where and there would be no reusability. As just locating the same component in another project will require digging, finding the missing styles which have to be picked up from other places.

 Recap of the most important rules:

• Keep all global styles in a separate file.
• Keep styles of components(pages, layouts) in isolation all the time.
• Keep the same name across the javascript file name, component name, style file name, and style class name.

These simple rules will make your system effectively maintain and scale. As it will have predictable behavior what is super important on a scale. Navigation to the proper place in code with minimum effort, which will play a great role in your overall performance. When the application grows it's hard to remember all details and you have constantly navigated through the code.

You might think of, that's super simple! Yes, it is! But you can't imagine how hard to keep everybody on the same page and keep track that the process is to keep following it. Take the process seriously on the review process of pull requests and do train new people when they join a project.

Looking forward to your comments and feedback. Feel free also to share your way of working with styles in a large application.

Further Reading

Scale Your Frontend Application

DRYing Up CSS

CSS Position: Relative vs Position Absolute