DEV Community: Iliya.Faz

useEffect in React: Summarized

Iliya.Faz — Fri, 31 Jan 2025 18:21:38 +0000

First, we need to understand 3 things:

trigger
render
commit

These are the 3 steps taken in order for a component to be displayed on the screen.

First, a render is triggered.

For instance:

function Component({ text }) {
  return <div>{text}<div/>
}

// triggering the component:
<Component text="hello" />

Then, the component is rendered, meaning React calls your component to figure out what to display on screen.
( In the example above, React would call <Component text="hello"/> and after doing the calculations come to the conclusion that it should look like <div>hello</div> in the DOM )
Finally, the DOM is modified to match the component.
Either the component is appended to it (while mounting for instance) or it's updated. This is what we call "commit".

Side note: Mounting refers to when your React component is first rendered.

Note: commit only takes place if the rendered component is different from the real DOM element. And if it isn't, it will make the minimum amount of modifications required to update the element and sync it with the component.

useEffect runs on every commit

useEffect is a React hook that runs after the render is committed to the DOM, whereas other logic is typically executed when the component is being rendered, before it is updated in the real DOM.

For instance, to put it simply:

<Component text="hello"/> triggers a render.
It's rendered and converted into <div>hello</div>
It's appended to the DOM.

And then it would be time for useEffect to do its job!

Examples use cases include:

When you want to access real DOM elements.
For instance, when you're looking to pause a video player using its reference with ref.current.pause();.
Running the piece of code above outside of useEffect will throw an error, because it's executed before the video player element is appended to the DOM! putting it into a useEffect however will make sure it's executed only after the rendering and committing process is complete.
If you want to prevent useEffect from running on every re-render, use a dependency array. The dependency array tells React that it should skip re-running your Effect if your dependencies (the items in the array) are the same as they were during the previous render.

Different useEffect behaviours:

Here's a very simple demonstration from the official react docs:

useEffect(() => {  
// This runs after every render  
});  

useEffect(() => {  
// This runs only on mount (when the component appears)  
}, []);  

useEffect(() => {  
// This runs on mount *and also* if either a or b have changed since the last render  
}, [a, b]);

Cleanup functions

Cleanup functions are functions you return in your useEffect hook.
React will call your cleanup function each time before the Effect runs again, and one final time when the component unmounts (gets removed).

useEffect(() => {
  // effect;
  return () => {
   // cleanup;
  };
}, []);

You could sort of think of the cleanup function as a function that stops everything the Effect is doing.

If your Effect subscribes to something, the cleanup function should unsubscribe.
If your Effect animates something in, the cleanup function should reset the animation to the initial values.
If your Effect fetches something, the cleanup function should either abort the fetch or ignore its result.

Here's a more realistic example:
Side note: If you're not familiar with AbortController have a look at here
It's pretty much used to cancel ongoing requests in here.

useEffect(() => {
  const controller = new AbortController();
  const signal = controller.signal;
  fetch(API, {
    signal: signal,
  })
    .then((response) => response.json())
    .then((response) => {
      // handle success
    });
  return () => {
    // cancel the request before component unmounts
    controller.abort();
  };
}, []);

Not an Effect: Initializing the application

Some logic should only run once when the application starts. You can put it outside your components:

if (typeof window !== 'undefined') { // Check if we're running in the browser.  
  checkAuthToken();  
  loadDataFromLocalStorage();  
}

function App() {  
// ...  
}

This guarantees that such logic only runs once after the browser loads the page.

Parts of the article are taken from the react docs, Credits to them for that!
If I happened to make a mistake, make sure to let me know.
See you on the next one!

Creating Truly Reusable React Components: A Comprehensive Guide

Iliya.Faz — Thu, 18 Jul 2024 18:48:32 +0000

In this article, we will go through the process of creating fully reusable React components from scratch.
Note that in a typical codebase, you'd probably copy & paste these components instead of writing them from scratch, so the implementation isn't as time consuming as it might look like 😅.

All CSS is written with Tailwindcss in this article.

Introduction 🚀

You can think of React components as building blocks of the web.
A component can be a navbar, footer, form, button, or any other piece of the front end.

They serve the same purpose as JavaScript functions, but work in isolation and return HTML.

Source

Code reusability refers to writing code in such a way that it can be reused across multiple contexts with little or no modification required. This approach saves time on repetitive tasks, shrinks codebase size, and improves maintainability.

Source

Reusable React components are components that can be used multiple times throughout an application to prevent unnecessary boilerplate.

Whenever possible, I prefer to create reusable components for common UI elements (e.g., buttons, text inputs, etc) and use them in the application like a component library, Instead of creating a separate component for each instance of the element.
This approach makes the code base cleaner, reduces code duplication and scales really well.

To give you an idea of how the process is done, we will create a fully reusable Button component in React. Note that any other type of reusable component is implemented in pretty much the same way.

Let's take a look at an example to help understand the concept.

For demonstration purposes, we'll recreate the list of buttons in the image below

Step 0: Creating a simple button component

First, we're gonna start off with the home button.

// home-button.tsx
const HomeButton = () => {
  return (
    <button className="rounded-md px-3 py-2 bg-blue-600 text-white hover:bg-blue-600/90">
      Home
    </button>
  );
};

export default HomeButton;

Then we will copy and paste the code for the remaining buttons and make the necessary modifications.

// profile-button.tsx
const ProfileButton = () => {
  return (
    <button className="rounded-md px-3 py-2 bg-blue-600 text-white hover:bg-blue-600/90">
      Profile
    </button>
  );
};

export default ProfileButton;

// settings-button.tsx
const SettingsButton = () => {
  return (
    <button className="rounded-md px-3 py-2 bg-blue-600 text-white hover:bg-blue-600/90">
      Settings
    </button>
  );
};

export default SettingsButton;

and this is how we would include them in our app:

<HomeButton/> <ProfileButton/> <SettingsButton/>

And... boom! here it is.

Why this is actually a bad approach ❌

While this does work, it comes with a bunch of problems, one of the notable ones being too much unnecessary boilerplate.
We just created 3 separate components for essentially the same thing. Imagine you're working on a large application where there are thousands of buttons like this. Making a separate component for each one would create loads of unnecessary boilerplate and quickly turn into an absolute mess.

Not to mention, making modifications to the component would be an absolute nightmare. You'd have to go through the code base and modify each component one by one!

Step 1: Making the button component reusable

First off, instead of including each button's label directly in its component, we could pass it off as a prop!

// button.tsx
const Button = ({ children }) => {
  return (
    <button className="rounded-md px-3 py-2 bg-blue-600 text-white hover:bg-blue-600/90">
      {children}
    </button>
  );
};

export default Button;

And then modify the code to look like this:

   <Button>Home</Button>
   <Button>Profile</Button>
   <Button>Settings</Button>

Same result, better code.

Now we've got 1 component instead of 3! That's a huge improvement, but we've still got a major problem: Customization.

Step 2: implementing className prop

What if you wanted to customize a button's appearance, without having to create a new component for it?

For example, let's say we want to make something like the image below.

Well, with our current component, we can't!
Because a fixed set of classNames is applied to every button element with no way to customize it.

Let's make it so that you can pass className as a prop.
(Like this)

  <Button className="bg-neutral-700 text-foreground">
    Home
  </Button>

Note: If you're not using tailwind, you can skip this step. Just take 'className' as a prop and add it to the list of classNames and you should be good to go.

Bad implementation ❌

Take a look at the button component below.

const Button = ({ children, className = "" }) => {
  const defaultStyle = "rounded-md px-3 py-2 bg-blue-600 text-white hover:bg-blue-600/90";
  // anything passed as 'className' is directly added to button's className prop
  return (
    <button className={`${defaultStyle} ${className}`}>
      {children}
    </button>
  );
};

export default Button;

We're basically taking className as a prop and adding it to the button element's list of classNames.

Let's try applying text-black to the element to see if it works.

<Button className="text-black">Test</Button>

Button element resulted from the code above:

<button className="rounded-md px-3 py-2 bg-blue-600 text-white hover:bg-blue-600/90 text-black">Test</button>;

Take a close look at the list of classNames above.

Expected behaviour: text-white should be replaced by text-black
Result: text-black is added but text-white isn't removed.

So in short, we've got both text-white and text-black in the same list of classNames which could lead to unexpected behaviour.

To fix this, we'll use a library called tailwind-merge.

twMerge (6.7k gzipped)

tailwind-merge is a library that allows us to merge two sets of Tailwindcss classNames into one.

for example:

twMerge('text-white bg-white', 'text-black text-xl')
// output: 'text-black bg-white text-xl'

// notice how text-white was replaced with text-black?
// without twMerge, this would output:
'text-white bg-white text-black text-xl'

More about tailwind-merge Here

In here, we'll use twMerge to merge the default classNames with the classNames provided as a prop (to prevent potential conflicts)

import React from "react";
import { twMerge } from "tailwind-merge";

const Button = ({ children, className }) => {
  const defaultStyle = "rounded-md px-3 py-2 bg-blue-600 text-white hover:bg-blue-600/90"

  return (
    <button
      className={twMerge(defaultStyle, className)}>
      {children}
    </button>
  );
};

export default Button;

There you go! Now we can use className without having to worry about potential className conflicts.

Step 3: implementing support for attributes

We're now one step closer to the final result! But there's still a huge problem, what if we wanted to use other button attributes? like onClick, onFocus, type, name, or even our own custom attributes.

  <Button
// not working
    onClick={onClickHandler}
    type="submit"
    custom-attribute="custom value">
    Button
  </Button>

With our current implementation, such attributes would not be applied to the button element.

This is how you'd fix that:

import { twMerge } from "tailwind-merge";

// "...props" gets all remaining props
const Button = ({ children, className, ...props }) => {
  const defaultStyle = "rounded-md px-3 py-2 bg-blue-600 text-white hover:bg-blue-600/90";
  return (
    <button
      className={twMerge(defaultStyle, className)}
      // applying other props
      {...props}>
      {children}
    </button>
  );
};

export default Button;

First, we're extracting children and className from props
Then we're getting the remaining props as props by using the spread operator
And finally, we're applying them to the button element with {...props}.

Step 4: Improving Re-usability and Readability with variants

I would consider what we've made so far to be quite re-usable, but there are still a few things we can do to make it even better.

One thing that really reduces boilerplate is implementing variants for common variations of the UI component such as size, color, etc.

Why use variants in the first place?

Using the className prop enables us to customize buttons when needed. But I prefer to only use it as a last resort since it comes with a bunch of boilerplate. If there is a certain button style (other than our default one) we'd want to use all over our application, we should create a variant for it instead of copy & pasting the list of custom classNames everywhere.

For instance, imagine a set of default (primary), secondary, outline and ghost buttons we'd be looking forward to use all over the code base.

This is how the implementation would look like:

      <Button>Default button</Button>
      <Button className="bg-neutral-700 text-neutral-50 hover:bg-neutral-700/90">
        Secondary button
      </Button>
      <Button className="border border-black text-black bg-transparent hover:bg-black/10">
        Outline button
      </Button>
      <Button className="bg-transparent text-black hover:bg-black/10">
        Ghost button
      </Button>

It would look quite messy if we had to copy and paste the same set of classNames for each instance of the button.

What if we could specify each button's style by using a simple variant prop?

      <Button>Default button</Button>
      <Button variant="secondary">Secondary button</Button>
      <Button variant="outline">Outline button</Button>
      <Button variant="ghost">Ghost button</Button>

Much cleaner now, isn't it?
Well, this is where variants come in handy!
In this example, we will implement two useful variants for our component:
size and variant (quite literally 😅)

In order to implement variants we're going to use class-variance-authority

cva (756 bytes gzipped)

class-variance-authority is the main library we're going to use to implement variants.
More about class-variance-authority Here

The library provides a function called 'cva'.
Take a look at the following example to get a brief overview of how cva is used.

const componentVariants = cva('text-black',
  {
    variants: {
// variants such as 'size', 'color' etc are supposed to be here
      color: {
        blue: "bg-blue-500",
        red: "bg-red-500",
        white: "bg-white",
      }
    },
    defaultVariants: {
// We'll set the color to blue if nothing is specified.
      color: "blue",
    },
  }
);

The first parameter of cva takes in the list of classNames we want to be applied to all variants. Useful for general layouts and transitions.
In the second parameter we specify variants and their corresponding classNames. For example, if blue is selected as the color variant, bg-blue-500 will be applied to the element.
We can also use defaultVariants to specify which variant to apply by default when nothing is specified.

Now we're gonna use componentVariants like this:

console.log(componentVariants({ color: "red" }));
// output: text-black bg-red-500
console.log(componentVariants({ color: "blue" }));
// output: text-black bg-blue-500
console.log(componentVariants());
// output: text-black bg-blue-500

You probably know how it works by now.
So let's use it to build different variants for our button component.

import { twMerge } from "tailwind-merge";
import { cva } from "class-variance-authority";

const buttonVariants = cva(
  `inline-flex items-center justify-center rounded-md whitespace-nowrap 
  ring-offset-background transition-colors focus-visible:outline-none 
   disabled:pointer-events-none disabled:opacity-50 relative overflow-hidden`,
  {
    variants: {
      variant: {
        default: "bg-primary text-neutral-100 hover:bg-primary/80",
        secondary: "bg-secondary text-foreground hover:bg-secondary/80",
        outline: "border border-ring text-foreground bg-background hover:bg-secondary/80",
        ghost: "text-foreground hover:bg-secondary/80",
        link: "text-primary underline-offset-4 hover:underline",
      },
      size: {
        default: "text-base px-3 py-2",
        sm: "text-sm rounded-md px-2 py-1.5",
        lg: "text-xl rounded-md px-4 py-3",
      },
    },
    defaultVariants: {
      variant: "default",
      size: "default",
    },
  }
);

const Button = ({ children, className, variant, size, ...props }) => {
  return (
    <button className={twMerge(buttonVariants({ variant, size }), className)} {...props}>
      {children}
    </button>
  );
};

export default Button;

In the end, we get the corresponding list of classNames from buttonVariants({ variant: <variant> }) and pass them to twMerge, which will merge them with custom classNames if any are provided.

Step 5: Implementing support for refs with React forwardRef

What if we wanted to us refs with our components? They're supposed to be 100% reusable so this should be a feature.

Picture this:

 const buttonRef = React.useRef(null);

  return <Button ref={buttonRef}>Default button</Button>;

This can be extremely useful in components like inputs.

React's forwardRef allows function components to be given refs.
To opt in, wrap your component definition into forwardRef():

const Button = React.forwardRef(({ children, className, variant, size, ...props }, ref) => {
  return (
    <button
      ref={ref}
      className={twMerge(buttonVariants({ variant, size }), className)}
      {...props}>
      {children}
    </button>
  );
});

(Make sure to import React if you haven't already)

Step 6: Final tweaks

clsx integration

From the official docs:

clsx is a tiny (239B) utility for constructing className strings conditionally.

import { clsx } from 'clsx';

// Strings (variadic)
clsx('foo', true && 'bar', 'baz');
//=> 'foo bar baz'

// Objects
clsx({ foo:true, bar:false, baz:isTrue() });
//=> 'foo baz'

More about clsx here

Wrap className with clsx and boom! Now we can use the clsx syntax to apply classNames conditionally.

    <button className={twMerge(buttonVariants({ variant }), clsx(className))} {...props}>
      {children}
    </button>

To reduce boilerplate, we can create a simple cn helper function which is basically a shortcut for wrapping the input in both clsx and twMerge.

[Credits to ShadcnUI for the idea]

// lib/utils.js
import { twMerge } from "tailwind-merge";
import { clsx } from "clsx";

export function cn(...classes) {
  return twMerge(clsx(classes));
}

Typescript version:

// lib/utils.ts
import { twMerge } from "tailwind-merge";
import { ClassValue, clsx } from "clsx";

export function cn(...classes: ClassValue[]) {
  return twMerge(clsx(classes));
}

Finally, we edit our button component to use cn instead of twMerge and clsx

import { cn } from "../lib/utils";

    <button className={cn(buttonVariants({ variant, size, className }))} {...props}>
      {children}
    </button>

And with that, we've finished building our entirely reusable button component.
You can customize it in however way you'd like.
In the same way, you can build other reusable components (inputs, modals, dropdowns, etc)

Here's the final result:
✅ Supports custom labels
✅ Supports custom classNames
✅ Supports custom attributes
✅ Supports different variants and sizes
✅ Supports conditional classNames with clsx syntax
✅ Supports refs

import React from "react";

import { cva } from "class-variance-authority";
import { cn } from "../lib/utils";

const buttonVariants = cva(
  `inline-flex items-center justify-center rounded-md whitespace-nowrap 
  ring-offset-background transition-colors focus-visible:outline-none 
   disabled:pointer-events-none disabled:opacity-50 relative overflow-hidden`,
  {
    variants: {
      variant: {
        default: "bg-primary text-neutral-100 hover:bg-primary/80",
        secondary: "bg-secondary text-foreground hover:bg-secondary/80",
        outline: "border border-ring text-foreground bg-background hover:bg-secondary/80",
        ghost: "text-foreground hover:bg-secondary/80",
        link: "text-primary underline-offset-4 hover:underline",
      },
      size: {
        default: "text-base px-3 py-2",
        sm: "text-sm rounded-md px-2 py-1.5",
        lg: "text-xl rounded-md px-4 py-3",
      },
    },
    defaultVariants: {
      variant: "default",
      size: "default",
    },
  }
);

const Button = React.forwardRef(({ children, className, variant, size, ...props }, ref) => {
  return (
    <button
      ref={ref}
      className={cn(buttonVariants({ variant, size, className }))}
      {...props}>
      {children}
    </button>
  );
});

export default Button;

Typescript version:

import React from "react";

import { cva, type VariantProps } from "class-variance-authority";
import { cn } from "../lib/utils";

const buttonVariants = cva(
  `inline-flex items-center justify-center rounded-md whitespace-nowrap 
  ring-offset-background transition-colors focus-visible:outline-none 
   disabled:pointer-events-none disabled:opacity-50 relative overflow-hidden`,
  {
    variants: {
      variant: {
        default: "bg-primary text-neutral-100 hover:bg-primary/80",
        secondary: "bg-secondary text-foreground hover:bg-secondary/80",
        outline: "border border-ring text-foreground bg-background hover:bg-secondary/80",
        ghost: "text-foreground hover:bg-secondary/80",
        link: "text-primary underline-offset-4 hover:underline",
      },
      size: {
        default: "text-base px-3 py-2",
        sm: "text-sm rounded-md px-2 py-1.5",
        lg: "text-xl rounded-md px-4 py-3",
      },
    },
    defaultVariants: {
      variant: "default",
      size: "default",
    },
  }
);

type ButtonProps = React.ButtonHTMLAttributes<HTMLButtonElement> &
  VariantProps<typeof buttonVariants>;

const Button = React.forwardRef<HTMLButtonElement, ButtonProps>(
  ({ children, className, variant, size, ...props }, ref) => {
    return (
      <button
        ref={ref}
        className={cn(buttonVariants({ variant, size, className }))}
        {...props}>
        {children}
      </button>
    );
  }
);

export default Button;

If I made a mistake, make sure to let me know.
See you on the next one!