DEV Community: Adrien Rahier

Exporting Styled Component variants in reusable components

Adrien Rahier — Fri, 12 Mar 2021 12:04:25 +0000

In the first part of this serie we have seen how to create Styled Component variants within the same file.

Now, let's say you want to create a multi-variant component that is reused all-across you app. How would you do this in a scalable way?

Solution

Over time, I have tried several techniques to do this (more about this at the end of this article) but one really shined.
Creating an extra Wrapper around the Default Component!

import styled from 'styled-components';

// Note that having a default class is important
const StyledCTA = ({ className = 'default', children }) => {
    return <Wrapper className={className}>{children}</Wrapper>;
};

/*
 * Default Button styles
 */
const Wrapper = styled.button`
    color: #000;
`;

/*
 * Custom Button Variant 1
 */
export const StyledCTAFushia = styled(StyledCTA)`
    && {
        color: fuchsia;
    }
`;

/*
 * Custom Button Variant 2
 */
export const StyledCTADisabled = styled(StyledCTA)`
    && {
        color: ${(props) => props.theme.colors.grey.light};
    }
`;

export default StyledCTA;

Usage

import StyledCTA, { StyledCTADisabled, StyledCTAFushia } from 'components/StyledCTA';

const Page = () => {
    return (
        <>
            <StyledCTA>Default CTA</StyledCTA>
            <StyledCTADisabled>Disable CTA</StyledCTADisabled>
            <StyledCTAFushia>Fuchsia CTA</StyledCTAFushia>
        </>
    )
};

Additional techniques

For some more advance usage I would also recommend using composable CSS variables.

Another alternative is also to use a dedicated library on top of Styled Components.

A scalable approach to Styled Component Variants

Adrien Rahier — Fri, 12 Mar 2021 11:38:20 +0000

On several occasions I saw people asking the question: "What's the best way to create variants using Styled components?"

And, because this variant feature is not natively supported by Styled Components I saw different people have different ways to approach this issue.

So, today I wanted to show you a couple of solutions that actually scales.

Note that this post will be split into two parts.
In this first one we are going to focus on how to create Styled Component variants within the same file.

The problem with if else or switch statements

Let's start by creating a simple Styled Component button with 3 variants:

const ButtonStyle = styled.button`
  color: ${({ theme, flashy, disabled }) => {
    if (flashy) return "fuchsia";
    else if (disabled) return theme.grey;
    else return theme.primary;
  }};
`;

As you can see, here you will have to maintain an if else (or switch) condition every time.
Obviously you could externalise this to a specific function determineColor but, still, the problem remains.

Solution 1

I have seen some people writing the same code as above in a more readable fashion:

const ButtonStyle = styled.button`
  color: ${(props) => props.theme.primary};
  ${({ variant }) =>
    variant == "flashy" &&
    css`
      color: "fushia";
    `}
  ${({ variant }) =>
    variant == "disabled" &&
    css`
      color: ${(props) => props.theme.grey};
    `};
`;

Unfortunately, here again, you are kinda using an if-else statement.

Solution 2 using inheritance

My preferred solution is actually to use the built-in inheritance property of styled-components.

const ButtonStyle = styled.button`
    color: ${(props) => props.theme.primary};
`;

const ButtonStyleFlashy = styled(ButtonStyle)`
    color: fuchsia;
`;

const ButtonDisabled = styled(ButtonStyle)`
    color: ${(props) => props.theme.grey};
`;

Here, ButtonStyleFlashy and ButtonDisabled inherits the CSS from ButtonStyle.

Zooming out

As a rule of thumb when I am creating styled component variants within the same file

▶️ If I am sure that the component will have exactly 2 variants I will use a Boolean props

const ParagraphVariant = styled.p`
    font-weight: ${(props) => (props.$bold ? `bold` : `normal`)};
`;

▶️ If the component has x variants then I will use inheritance as seen above.

Creating a custom React hook to get the window's dimensions in Next.js

Adrien Rahier — Mon, 15 Feb 2021 14:55:32 +0000

While working on the Front End of a React App, it's likely that at some point you will need to access the window's dimension.

The classic implementation

To keep your code DRY a general good practice is to externalise this operation to a custom React hook.
Something like this:



// useWindowDimension.js
const [width, setWidth]   = useState(window.innerWidth);
const [height, setHeight] = useState(window.innerHeight);
const updateDimensions = () => {
    setWidth(window.innerWidth);
    setHeight(window.innerHeight);
}
useEffect(() => {
    window.addEventListener("resize", updateDimensions);
    return () => window.removeEventListener("resize", updateDimensions);
}, []);

return { width, height};

While everything works fine in this traditional client-side apps built with React (like create-react-app) problems arise in Gatsby or Next.js.

The SSR inferno

The main problem with Next and Gatsby is that they run the code both on the FE and on the BE... Where window is obviously not defined.
So, how to get around this I hear you ask?

Well, you could do write something like this, where you check if the window is defined or not before continuing.



// useWindowDimension.js
import { useState, useEffect } from 'react';

export default function useWindowDimensions() {

  const hasWindow = typeof window !== 'undefined';

  function getWindowDimensions() {
    const width = hasWindow ? window.innerWidth : null;
    const height = hasWindow ? window.innerHeight : null;
    return {
      width,
      height,
    };
  }

  const [windowDimensions, setWindowDimensions] = useState(getWindowDimensions());

  useEffect(() => {
    if (hasWindow) {
      function handleResize() {
        setWindowDimensions(getWindowDimensions());
      }

      window.addEventListener('resize', handleResize);
      return () => window.removeEventListener('resize', handleResize);
    }
  }, [hasWindow]);

  return windowDimensions;
}

Note that at this time of writing this is currently the highest voted answer on Stackoverflow regarding Next.js implementation.
However, trying this code out will trigger a warning in Next:

So, why is this code flawed and how can we make it bullet-proof?

The solution

It's only after reading Josh's W Comeau that I got a sense of the problem. With the implementation above we are actually bypassing the Rehydration process by checking if the window object is defined or not!
A better implementation would be to actually make sure that the component has mounted (and use the useEffect hook).

The final custom hook looks like this, and everybody is happy!



/**
 * // useWindowDimension.ts
 * * This hook returns the viewport/window height and width
 */

import { useEffect, useState } from 'react';

type WindowDimentions = {
    width: number | undefined;
    height: number | undefined;
};

const useWindowDimensions = (): WindowDimentions => {
    const [windowDimensions, setWindowDimensions] = useState<WindowDimentions>({
        width: undefined,
        height: undefined,
    });
    useEffect(() => {
        function handleResize(): void {
            setWindowDimensions({
                width: window.innerWidth,
                height: window.innerHeight,
            });
        }
        handleResize();
        window.addEventListener('resize', handleResize);
        return (): void => window.removeEventListener('resize', handleResize);
    }, []); // Empty array ensures that effect is only run on mount

    return windowDimensions;
};

export default useWindowDimensions;

Usage:



import { useWindowDimensions } from '@hooks/useWindowDimensions';
...
const { width, height } = useWindowDimensions();