DEV Community: Ece Tunca

A simple way of adding dark mode to your React app using Hooks and saving it to the local storage

Ece Tunca — Wed, 14 Oct 2020 11:06:52 +0000

In this article I will share my approach for the dark/light mode toggle that I recently implemented in a React project, which I think is quite easy to understand also for beginners.

First I add a <span> element into my App.tsx file. It can either be a <button>, <div>, whatever you prefer. This will act as a switch for dark/light mode :

import React, { useEffect, useState } from 'react';

function App() {
    return (
      <div className='container'>
        <span className='mode-switch'></span>
        {/* my other elements */}
      </div>
    )
}

export default App;

Then I add some basic styles. I prefer my switch to be positioned absolutely on the right top corner of my container element:

.container {
  position: relative;
  max-width: 1400px;
  padding: 40px 30px;
}

.mode-switch {
  position: absolute;
  right: 15px;
  top: 15px;
  font-size: 11px;
  cursor: pointer;
  transition: color 0.2s ease-in-out;

  &:hover {
    color: #50bbf1;
  }
}

I go back to my App component and add the useState hook. I define a mode variable and a setMode function. For now I pass the default mode as 'light' inside the useState hook.
Then I add an onClick event to my switch and in this event, I call the setMode function with a conditional parameter.
This function makes sure that it sets the mode to dark if it was light, and vice versa.
I also add the text content into the switch dynamically :

function App() {
    const [mode, setMode] = useState('light'); 

    return (
      <div className='container'>
        <span 
           className='mode-switch'
           onClick={() => 
             setMode(mode === 'dark' ? 'light' : 'dark')
           }
        >
           {mode === 'dark' ? 'Light mode' : 'Dark mode'}
        </span>
      </div>
    )
}

Next step is switching between modes and adding/removing relevant styles, which will be achieved using the useEffect hook.
It will simply add a '.dark' class to the <body> when switched to the dark mode, and remove it when the selected mode is light.
I pass [mode] as the second parameter to useEffect because it will work as the side effect of the changing 'mode':

function App() {
    const [mode, setMode] = useState('light'); 

    useEffect(() => {
      if (mode === 'dark') {
        document.body.classList.add('dark');
      } else {
        document.body.classList.remove('dark');
      }
    }, [mode]);

    return (

Then I add the necessary styles, which make the background-color black and turn all the text to white if they were not originally assigned any color and were black by default:

.dark {
  background-color: #222;
  color: #f5f5f5; 
}

In order to style other elements other than the <body> in dark mode, I use the & selector.
Let's say I have a button with 'primary-button' class. I want to change its color and background-color when the dark mode is active:

.primary-button {
  // default style: black button with white text
  background-color: #222;
  color: #f5f5f5;

  // dark mode style: white button with black text 
  .dark & {
    background-color: #f5f5f5;
    color: #222;
  }
}

Now it's time to save the selected mode to the local storage, so that the selected mode will persist even if the app is reset. To achieve this, first I go back to the useEffect hook and include the following code into it:

useEffect(() => {
  if (mode === 'dark') {
     document.body.classList.add('dark');
  } else {
     document.body.classList.remove('dark');
  }
  localStorage.setItem('mode', mode); // mode saved to local storage
}, [mode]);

Then I go up and create a utility function called getDefaultMode on a global level. This function will get the saved mode from the local storage and determine the default mode accordingly when the app starts. If dark mode was not selected previously, the default mode will be 'light':

function getDefaultMode() {
  const savedMode = localStorage.getItem('mode');
  return savedMode ? savedMode : 'light';
}

Now I need to call this function inside the useState hook that I previously added inside my App component. I replace the light parameter with the getDefaultMode function:

const [mode, setMode] = useState(getDefaultMode());

The final code looks like this in the end:

import React, { useEffect, useState } from 'react';

function getDefaultMode() {
  const savedMode = localStorage.getItem('mode');
  return savedMode ? savedMode : 'light';
}

function App() {
    const [mode, setMode] = useState(getDefaultMode()); 

    useEffect(() => {
      if (mode === 'dark') {
        document.body.classList.add('dark');
      } else {
        document.body.classList.remove('dark');
      }
      localStorage.setItem('mode', mode);
    }, [mode]);

    return (
      <div className='container'>
        <span 
           className='mode-switch'
           onClick={() => 
             setMode(mode === 'dark' ? 'light' : 'dark')
           }
        >
           {mode === 'dark' ? 'Light mode' : 'Dark mode'}
        </span>
        {/* my other elements */}
      </div>
    )
}

Dealing with the Scope Issues of BEM

Ece Tunca — Sun, 31 May 2020 18:52:32 +0000

It is hard to agree on coding conventions. When it comes to CSS, it is usually challenging when you try to implement a comprehensible, clean and reusable code, especially if you are working as a team of developers for a single project. Every developer might have different points of view on these concepts, and with the lack of a CSS naming convention that has been agreed upon, it is inevitable to end up with a messy code, which will turn further development and debugging into a nightmare. Adopting a naming convention will save you hours even if you are the only developer.

BEM (Block Element Modifier) has been one of the most widely used, and at the same time, the most hotly debated naming conventions in the recent years. While BEM provides you with a modular, consistent and systematically written code, it is usually criticised for its naming scheme causing some sort of ugliness. I agree that class names chosen for the sake of specificity can look ugly especially when they are repetitive and used together with grandchild selectors. When combined with SASS, elements and modifiers might create multiple levels of nested components, ending up with complexity and of course, ugliness.

Rather than being the result of the problematic nature of BEM, I believe that these issues usually derive from the wrongly made decisions while determining the block scopes.

Let's say you want to make a simple site header that contains a primary menu and a secondary menu.
Let's code it in an ugly manner:

<header class="header">
    <ul class="header__menu header__menu--primary">
        <li class="header__menu__item">
            <a class="header__menu__item__link" href="#"></a>
        </li>
        <li class="header__menu__item">
            <a class="header__menu__item__link" href="#"></a>
        </li>
        <li class="header__menu__item">
            <a class="header__menu__item__link" href="#"></a>
        </li>
    </ul>
    <ul class="header__menu header__menu--secondary">
        <li class="header__menu__item">
            <a class="header__menu__item__link" href="#"></a>
        </li>
        <li class="header__menu__item">
            <a class="header__menu__item__link" href="#"></a>
        </li>
        <li class="header__menu__item">
            <a class="header__menu__item__link" href="#"></a>
        </li>
    </ul>
</header>

The first problem that catches one's eye is the existence of grandchild selectors .header__menu__item and .header__menu__item__link, which are problematic to use and should be avoided. Here, the issue of determining the block scope comes into play. Does .header__menu have to be an element of the .header block? What about setting it as a free, self-standing block? Maybe we would want to use the same menu somewhere else as well, in the site footer for instance?

<header class="header">
    <ul class="menu menu--primary">
        <li class="menu__item">
            <a class="menu__link" href="#"></a>
        </li>
        <li class="menu__item">
            <a class="menu__link" href="#"></a>
        </li>
        <li class="menu__item">
            <a class="menu__link" href="#"></a>
        </li>
    </ul>
    <ul class="menu menu--secondary">
        <li class="menu__item">
            <a class="menu__link" href="#"></a>
        </li>
        <li class="menu__item">
            <a class="menu__link" href="#"></a>
        </li>
        <li class="menu__item">
            <a class="menu__link" href="#"></a>
        </li>
    </ul>
</header>

As we see, not only has the problem of grandchild selector been solved, but also the class names look shorter and cleaner. More importantly, we have a reusable menu block.

Now let's add some basic styles. The only difference between the primary and the secondary menu will be the width:

.menu {
    display: flex;
    list-style: none;

    &__item {
        margin: 0 1rem;
    }

    &__link {
        text-decoration: none;

        &:hover {
           text-decoration: underline; 
        }
    }

    &--primary {
        width: 50%;
    }

    &--secondary {
        width: 30%;
    }
}

Everything looks alright so far. What if we want to style the menu items differently? For instance, we want to assign different colours for menu items of primary menu and secondary menu. Although modifiers come in handy for additional styles, their usage should be limited to the blocks most of the times. Otherwise we would end up with something like this:

<ul class="menu menu--primary">
     <li class="menu__item menu__item--primary">
         <a class="menu__link" href="#"></a>
     </li>
     <li class="menu__item menu__item--primary">
         <a class="menu__link" href="#"></a>
     </li>
     <li class="menu__item menu__item--primary">
         <a class="menu__link" href="#"></a>
     </li>
 </ul>

Instead of adding modifiers to the .menu__item class, assigning additional styles to the element via the modifier of the block seems like a better approach:

&--primary {
    width: 50%;

    .menu__item {
        color: blue;
    }
}

&--secondary {
    width: 50%;

    .menu__item {
        color: green;
    }
}

While we can use the .menu__item class nested directly inside the modifier as above, using $self will improve your code even more:

.menu {
    $self: &; // first we assign the current scope to $self here
    display: flex;
    list-style: none;

    &__item {
        margin: 0 1rem;
    }

    &__link {
        text-decoration: none;

        &:hover {
           text-decoration: underline; 
        }
    }

    &--primary {
        width: 50%;

        #{$self}__item { // then we pass it here
            color: blue;
        }
    }

    &--secondary {
        width: 30%;

        #{$self}__item {
            color: green;
        }
    }
}

This is just a simple case that shows how the decisions regarding the block scope can effect the general quality, comprehensibility and appearance of the code. As your project gets more complex, initial planning of block scope gains more importance. Class names might still not be very appealing to the eye, but the consistency and predictability they provide will be invaluable to you and your team.