Cleanup Exercises

Fixing previous exercises

Now that we know how to manage cleanup, let's improve our solutions from previous exercises!

Window dimensions

Update our solution to the “Window dimensions” exercise so that the event listener is cleaned up.

Acceptance Criteria:

The "resize" event listener should be removed inside a cleanup function.

Code Playground

import React from 'react';

function WindowSize() {

const [

windowDimensions,

setWindowDimensions,

] = React.useState({

width: window.innerWidth,

height: window.innerHeight,

});

React.useEffect(() => {

function handleResize() {

console.log('resize');

setWindowDimensions({

width: window.innerWidth,

height: window.innerHeight,

});

}

window.addEventListener('resize', handleResize);

}, []);

return (

<p>

{windowDimensions.width} / {windowDimensions.height}

</p>

preview

console

Solution:

Toasty!

In the “Toasty!” exercise, we implemented an animation using IntersectionObserver, but we never cancel this process!

Here's the code required to stop an IntersectionObserver:

observer.disconnect()

Acceptance Criteria:

The IntersectionObserver should be disconnected within the effect's cleanup function.

Code Playground

/*

To stop an IntersectionObserver, you can run:

observer.disconnect();

*/

import React from 'react';

import styles from './Toasty.module.css';

function Toasty() {

const [isShown, setIsShown] = React.useState(false);

const wrapperRef = React.useRef();

React.useEffect(() => {

const observer = new IntersectionObserver((entries) => {

const [entry] = entries;

setIsShown(entry.isIntersecting);

});

observer.observe(wrapperRef.current);

}, []);

const translateX = isShown ? '0%' : '100%';

return (

<div

className={styles.character}

style={{

transform: `translateX(${translateX})`,

}}

>

👻

</div>

);

}

export default Toasty;

Solution:

Digital clock

Let's build a digital clock with React!

Below, you'll find a clock that initializes at the correct value, but it doesn't update. Your mission is to update the code so that the clock shows the correct time:

10:30:09 PM

Acceptance Criteria:

The clock should update once per second, to show the current time.
There should be no memory leaks, no ongoing processes that outlive the Clock instance.

Code Playground

import React from 'react';

import format from 'date-fns/format';

function Clock() {

const [time, setTime] = React.useState(new Date());

return (

{format(time, 'hh:mm:ss a')}

</p>

);

}

export default Clock;

preview

console

Solution:

Useless machine

Have you ever heard of “useless machines”? These small boxes are built by hobbyists, and have a single switch on them. When you flip the switch, the box flips it back:

It's a completely useless machine! But it's fun and whimsical.

Let's build something similar. We'll create a checkbox that automatically ticks itself, whenever it's unticked:

Acceptance Criteria:

When the user unticks the checkbox, it should become re-ticked automatically after half a second. This can be done with a setTimeout.
If the user toggles it off and on really quickly, the timeout should be canceled, since the machine has been left in an "on" state.
If the user clicks it a bunch of times in rapid succession, the machine should wait a full 500ms from the final click before ticking itself back on.

(Your checkbox might look a little bit different, depending on browser/OS.)

Code Playground

import React from 'react';

import VisuallyHidden from './VisuallyHidden';

function UselessMachine() {

const id = React.useId();

const [isOn, setIsOn] = React.useState(true);

return (

<>

<input

id={id}

type="checkbox"

checked={isOn}

onChange={event => {

setIsOn(event.target.checked);

}}

/>

Toggle checkbox

</label>

</VisuallyHidden>

</>

);

}

export default UselessMachine;

Solution:

Solution code (success)

import React from 'react';

import VisuallyHidden from './VisuallyHidden';

function UselessMachine() {
  const id = React.useId();
  const [isOn, setIsOn] = React.useState(true);

  React.useEffect(() => {
    // Ignore renders that happen because the
    // checkbox is flipped on. We only want to
    // respond when it's flipped *off*.
    if (isOn) {
      return;
    }

    // Flip the checkbox back on in 500ms...
    const timeoutId = window.setTimeout(() => {
      setIsOn(true);
    }, 500);

    return () => {
      // ...Unless the 'isOn' property changes
      // before that time has elapsed, OR the
      // component happens to unmount:
      window.clearTimeout(timeoutId);
    };
  }, [isOn]);

  return (
    <>
      <input
        id={id}
        type="checkbox"
        checked={isOn}
        onChange={(event) => {
          setIsOn(event.target.checked);
        }}
      />
      <VisuallyHidden>
        <label htmlFor={id}>Toggle checkbox</label>
      </VisuallyHidden>
    </>
  );
}

export default UselessMachine;

Early returns (info)

In my solution, I use an early return to bail out of the effect early.

Alternatively, I could have moved the entire effect logic into an if condition:

React.useEffect(() => {
  if (!isOn) {
    const timeoutId = window.setTimeout(() => {
      setIsOn(true);
    }, 500);

    return () => {
      window.clearTimeout(timeoutId);
    };
  }
}, [isOn]);

Both of these approaches are equally valid, but personally, I much prefer using an early return.

A well-written effect should have a single primary purpose. In this case, the primary purpose is to flip the machine back on when the user switches it off, after a 500ms timeout. That's why this effect exists. And this is what I want us to focus on.

Early returns allow us to emphasize an effect's primary purpose. We can clear away the conditions, so that they don't obfuscate the primary purpose.

This pattern is useful for all functions, not just React effects! And when we use it consistently, it makes it much easier for us to quickly understand what a function is doing. It's especially beneficial for more-complex functions with multiple conditions.

As another example: which of these two functions is easier for you to understand?

// Option 1
async function logInUser(email, password) {
  const user = await findUser(email);

  if (user) {
    const isValidPassword = await validatePassword(user, password);

    if (isValidPassword) {
      await startSession(user);
      return { user };
    } else {
      return { error: 'invalid password' };
    }
  } else {
    return { error: 'user not found' }
  }
}

// Option 2
async function logInUser(email, password) {
  const user = await findUser(email);

  if (!user) {
    return { error: 'user not found' }
  }

  const isValidPassword = await validatePassword(user, password);
  if (!isValidPassword) {
    return { error: 'invalid password' };
  }

  await startSession(user);
  return { user };
}

The primary purpose of this function is to log the user in. In Option 1, that primary purpose is buried in the middle of the function, nested within two if/else blocks.

In Option 2, we've flattened the structure, bailing out as soon as it's clear that a particular invocation is not fulfilling the function's primary purpose. As a result, we can skip to the bottom to see what the function's primary purpose is.

As I said, this is a subjective preference, but this is one of my favourite patterns. When followed consistently, early returns make it much easier to understand how complex code is structured, in my opinion.