Styling and Theme Management for React Apps

Mahdi Karimipour
4 min readJun 30, 2021

--

Context

Only when you work on applications with styles shared across multiple pages you appreciate how effective CSS Modules are. By definition, based on this repo, modules are CSS files in which all class names and animation names are scoped locally by default.

This is a huge advantage as you don’t have to worry about conflicting styles between various screens, while you still can refer to some central styling which have to stay the same across all your entire app.

It accelerates the whole development process as you can quickly change the styles of one component without worrying about what happens to other screens.

By the way, this topic belongs to the series to set up a Single Page Application using React, Redux and Asp.NET 5.0.

  1. Styling and Theme Management
  2. Global Navigation
  3. Responsive Layout
  4. Forms and Input Validation
  5. Routing
  6. Configuration Management
  7. API Call and Activity Indicator (Spinner)
  8. Monitoring, Logging and Instrumentation
  9. Toast Notification
  10. Redux and Store Setup
  11. Google Maps with Polygons
  12. SEO — Search Engine Optimisation
  13. Running React App on .NET Stack
  14. Deploy React App to Azure App Service

Prerequisites

I assume you have used the create-react-app to create your React application.

Configuration

Configuring CSS (SCSS) modules is pretty easy and straightforward. You can define your scss elements in the same place as you define your component, or you could have them in separate files. I generally go with the separate, but it’s up to you and how you prefer it.

If you decided to have separate scss files, make sure you reference the file in your component, which then you can use that reference to select the classes for each element you want to apply that style to.

Defining the styles in a separate file, below you can find a sample scss file.

There are a few points to consider about this scss file.

1. Hierarchy Matters

I often define a container element, PageLink in this case, that represents the entire control, and then all the children fall under this container, based on where they are in the hierarchy.

This makes it so much easier to make sense of each element, and it also doesn’t apply unwanted styles to all the elements in the control; It is applied only to those which happen to be at a certain location in the control.

2. Media Queries

You can define media queries as you need them for each control. This makes it management so much easier, as again, the localised styles for different form factors (as well as device sizes) are defined in the same file.

Note

Configuration, plumbing and troubleshooting your software foundation take a considerable amount of time in your product development. Consider using Pellerex which is a complete foundation for your enterprise software products, providing source-included Identity and Payment functions across UI (React), API (.NET), Pipeline (Azure DevOps) and Infrastructure (Kubernetes).

3. Themes

Ideally you should be able to change the theme of all your web pages from a central place in your application. To make this easier, these are the elements you should define in a central file, such as variables.scss in our case:

  • Color Pallet: Injecting different variations of colors such as blue, orange, white, etc into all your style files will become a nightmare as your application grows. You might have different versions of orange in different files, and if one day you wanted to change it to blue, there are so many places to touch.
  • Fonts: Fonts are also another candidate that should go into the variable file, as you commonly you have a couple of fonts across the entire application, and you want them to be consistent.
  • Measurements: A consistent styling across your application often include consistent margins, padding, etc. for containers and controls. These could also be defined in that file.

Here is an example of such file, containing the variables, that the rest of your application can refer to:

Pellerex Foundation: For Your Next Enterprise Software

How are you building your current software today? Build everything from scratch or use a foundation to save on development time, budget and resources? For an enterprise software MVP, which might take 8–12 months with a small team, you might indeed spend 6 months on your foundation. Things like Identity, Payment, Infrastructure, DevOps, etc. they all take time, while contributing not much to your actual product. These features are needed, but they are not your differentiators.

Pellerex does just that. It provides a foundation that save you a lot development time and effort at a fraction of the cost. It gives you source-included Identity, Payment, Infrastructure, and DevOps to build Web, Api and Mobile apps all-integrated and ready-to-go on day 1.

Check out Pellerex and talk to our team today to start building your next enterprise software fast.

--

--

No responses yet