Forem: Austin Ryan Taylor

useReducer – Demystifying React Hooks (Pt. 5)

Austin Ryan Taylor — Thu, 16 Feb 2023 22:04:21 +0000

In this article, we will explore when and how to use React’s useReducer hook
and how it relates to the useState Hook.

If you'd like to skim this as a Medium article, it can be found here

Getting Started

fork and clone
cd client
npm i
npm start

`useReducer`

The intended use case for useReducer is to manage complex state logic by
taking advantage of the
Flux/Redux
pattern. And if you don't know Redux, don't worry. In my opinion, useReducer
is the perfect place to start learning Redux.

Why Bother?

Imagine we wanted to pass down all three states for our user to alter them from
inside a child component. We'd have to pass six different values: each state
and its setter. useReducer can simplify our code by reducing all of
our state logic into a single function, aptly named a reducer. Reducers allow
us to pass predetermined actions to our state updater to avoid
unintentional state updates. We can even bake in custom error handling to make
debugging easier. Think of it as hand-rolling type-checking for your state. Kind
of... But we're not going down that rabbit hole today.

Starter Code

As always, let's start with a brief overview of the codebase before we refactor.

App.js has three sections: a counter, a theme changer, and a text input, all
of which we've neatly rolled into one component to spare us file surfing. Each
section has a dedicated instance of the useState hook, which we all know and
love.

We have three pieces of state: input, count, and darkMode.

Instead of updating our state inline, we've made four breakout functions:
handleChange, incrementCount, decrementCount, and changeTheme, each of
which does exactly what its name implies. The only thing to note here is that,
with incrementCount and decrementCount, we're using an
updater function
rather than directly passing the new state value. We've done this because the
next value of the state depends on the previous value. A longhand version of the
same function would look like this:

setCount(previousState => {
  return previousState + 1;
});

A Simple Refactor

Let's jump into our refactoring, one piece of state at a time. We'll start by
importing useReducer from 'react'.

import { useState, useReducer } from 'react';

Next, we'll initialize our state with useReducer.

const [state, dispatch] = useReducer(reducer, initialState);

`useReducer` Signature

useReducer looks a lot like useState. We're still destructuring an array
from the return and passing our initial values as arguments. However, you may
notice that, unlike useState, useReducer requires two arguments: a reducer
function and the initialState. The other difference is much more minor.

Our state is essentially the same, but rather than explicitly naming each
piece of state, the convention is to create a state object, and our
key/value pairs become our different "pieces" of state. The dispatch
function is still our state setter but requires an action object as a second
argument.

Refactoring Counter

First, we'll refactor the count state. We'll start by defining our
initialState variable. Typically this, along with the reducer function,
would be defined elsewhere and imported into our component. For simplicity's
sake, we'll define them in the same file, underneath our import statements but
not inside our component.

import {useState, useReducer} from 'react';

const initialState = {
  count: 0,
};

function App() {
  ...

Next, we'll define our reducer function in a "separate file" (same file, but
outside our component). This reducer function requires two arguments: our
state object and an action object. The action object will have two keys:
type and payload. Later, when we dispatch an action, the type tells
useReducer what we're trying to update, while the payload provides the
updated value.

const reducer = (state, action) => {};

Inside this reducer, we'll switch on the action's type property to determine
what to do. Of course, you could use any form of conditional logic, but a
switch statement is the convention.

const reducer = (state, action) => {
  switch (action.type) {
    case 'increment':
      return { count: state.count + 1 };
    case 'decrement':
      return { count: state.count - 1 };
    default:
      console.log(`Action ${action.type} not found.`);
      return state;
  }
};

Notice that in our default, we console.log some simple feedback and return
the unaltered state. So if we pass in an action type that doesn't exist,
instead of breaking our app, we're simply made aware that we've not yet built a
case to handle this situation. This error handling can be as simple or robust
as your company's style guide requires.

As our state complexity grows, we'll need to update and refactor our
reducer. But for now, we'll move on to our functions.

Now, in incrementCount and decrementCount, instead of calling setCount, we
call dispatch, and pass it the appropriate action as an object.

const incrementCount = () => {
  dispatch({ type: 'increment' });
};

const decrementCount = () => {
  dispatch({ type: 'decrement' });
};

And lastly, since count is now nested inside our state object, we need to
update our count reference in our JSX.

<p className='output'>{state.count}</p>

Now we can remove our count useState instance and test our App. It will work
the same! And you'll notice our other two pieces of state still work just fine.

That's great! We've added more code that's complicated our app and reduced
readability with no tangible advantages! How cool!

Settle down. Now is where we start to see some advantages. It's time to
reduce our state into a single object.

Refactoring darkMode

We'll start this process by adding darkMode to our initialState object. In
our case, the default is true because I'm a gremlin.

const initialState = {
  count: 0,
  darkMode: 'dark'
};

Next, we'll add a case to our reducer to handle the darkMode update.

const reducer = (state, action) => {
  switch (action.type) {
    case 'increment':
      return { count: state.count + 1 };
    case 'decrement':
      return { count: state.count - 1 };
    case 'darkMode':
      return { darkMode: action.payload };
    default:
      console.log(`Action ${action.type} not found.`);
      return state;
  }
};

As before, let's update our changeTheme function to dispatch the appropriate
action. This time, we need not only a type but also a payload. The type
will be darkMode, and the payload will be the opposite of darkMode's
current value.

const changeTheme = () => {
  dispatch({ type: 'darkMode', payload: !state.darkMode });
};

Lastly, we'll update the reference in our JSX.

<button onClick={changeTheme}>
  {state.darkMode ? 'light mode' : 'dark mode'}
</button>

Now you'll see that we can, again, toggle between light and dark modes! And if
we test our counter we find that...

We broke our app.

Luckily this is an easy fix. When we update our state object, it's completely
overwriting the previous state object, but we want to preserve all previous
values and only update the one being changed. So, in our reducer, all we need
to do is
spread
the current state before updating.

const reducer = (state, action) => {
  switch (action.type) {
    case 'increment':
      return { ...state, count: state.count + 1 };
    case 'decrement':
      return { ...state, count: state.count - 1 };
    case 'darkMode':
      return { ...state, darkMode: action.payload };
    default:
      console.log(`Action ${action.type} not found.`);
      return state;
  }
};

Works like a charm! We can now remove our darkMode useState instance.

Refactor `input`

Our last piece of state to update is our input. This will be the same process
as before.

First, we add an input to our initialState object.

const initialState = {
  count: 0,
  darkMode: true,
  input: ''
};

Next, we add a case to our reducer to handle the input update.

const reducer = (state, action) => {
  switch (action.type) {
    case 'increment':
      return { ...state, count: state.count + 1 };
    case 'decrement':
      return { ...state, count: state.count - 1 };
    case 'darkMode':
      return { ...state, darkMode: action.payload };
    case 'input':
      return { ...state, input: action.payload };
    default:
      console.log(`Action ${action.type} not found.`);
      return state;
  }
};

Next, we update our handleInputChange function to dispatch the appropriate
action.

const handleInputChange = e => {
  dispatch({ type: 'input', payload: e.target.value });
};

And lastly, we update our JSX to reference the proper input value.

<input
  type='text'
  value={state.input}
  onChange={handleInputChange}
/>
<p className='output'>{state.input.trim() || 'user input'}</p>

Now we can remove our last instance of useState and test our app.

It works! Congrats! You've just built your first React App that updates state
without useState!

Refactoring Our `action` Object

Now that our app is fully functional, there are a few more things we can do to
optimize our code. We'll start by refactoring our action object. Rather than
evaluating our state updates based on passing around strings, we can make our
action object a const that we then reference in our reducer. Not only does
this help us avoid typos, but if we need to update our action object, we only
need to do so in one place, making our app much more maintainable.

Again, in a "separate" file, we'll define a proper const using all caps.

const ACTION = {
  INCREMENT: 'increment',
  DECREMENT: 'decrement',
  DARK_MODE: 'darkMode',
  INPUT: 'input'
};

Now, in our reducer, instead of comparing action.type to a string, we can
compare it to ACTION.

const reducer = (state, action) => {
  switch (action.type) {
    case ACTION.INCREMENT:
      return { ...state, count: state.count + 1 };
    case ACTION.DECREMENT:
      return { ...state, count: state.count - 1 };
    case ACTION.DARK_MODE:
      return { ...state, darkMode: action.payload };
    case ACTION.INPUT:
      return { ...state, input: action.payload };
    default:
      console.log(`Action ${action.type} not found.`);
      return state;
  }
};

And in our dispatch calls, we'll remove the strings and reference the ACTION
const as our type.

const incrementCount = () => {
  dispatch({ type: ACTION.INCREMENT });
};

const decrementCount = () => {
  dispatch({ type: ACTION.DECREMENT });
};

const changeTheme = e => {
  dispatch({ type: ACTION.DARK_MODE, payload: !state.darkMode });
};

const handleInputChange = e => {
  dispatch({ type: ACTION.INPUT, payload: e.target.value });
};

You'll notice that this approach not only avoids typos and makes your code more
maintainable, but now your IDE offers you autocomplete suggestions.

The Tradeoffs

As with everything in development, there are tradeoffs. In this case, we seem to
have simplified our state by complicating it. Obviously, this is overkill for a
counter app with a random input field and a light/dark mode toggle. But as our
apps grow, we'll find that this pattern, while heavy on the setup, simplifies
overall. For example, take a look at this state tree from Airbnb. Or, head to
airbnb.com and see for yourself using the Redux DevTools.

Now, imagine a different useState hook for each of those values. And imagine
if you needed to pass these values around your app. There would be so much prop
drilling that your code would be entirely unreadable.

Conclusions

So, when should you use useState, and when should you use useReducer?

That, my friend, is up to you (or your future company's style guide and coding
principles). If you're able to accurately predict the complexity of your app,
the extra work to set up useReducer from the start might be worth it. If you
know you won't be scaling up, or you're okay with the future tech debt, maybe
you stick with useState. The most likely scenario is that you'll use a mixture
of both.

Either way, you now have the tools to make an informed decision. And that's
arguably more important than what you decide. And now that you're armed with
this knowledge, add a central store or some slices for your state, and you're
using Redux!

I’m always looking for new friends and colleagues. If you found this article helpful and would like to connect, you can find me at any of my homes on the web.
GitHub | Twitter | LinkedIn | Website

Resources

useLayoutEffect – Demystifying React Hooks (Pt. 4)

Austin Ryan Taylor — Thu, 16 Feb 2023 21:47:15 +0000

In this article, we will explore when and how to use React’s useLayoutEffect
hook and how it relates to the useEffect Hook.

If you’d like to clone this down and run it locally, you can find the repo here

Getting Started

fork and clone
cd client
npm i
npm start

Creating the Problem

Sure, useLayoutEffect is not something you'll use often. It actually took me
longer to think of a use case than to code out the example. It's kinda like
the US Supreme Court's definition of obscenity,
"You know it when you see it."

The React beta docs offer a cool, albeit incredibly specific use case with
"a tooltip that appears next to some element on hover. If there’s enough space, the tooltip should appear above the element, but if it doesn’t fit, it should appear below"...
if you'd like to check that out.

While you likely won't turn to useLayoutEffect often enough to need a snippet,
understanding how it works will help you better understand useEffect, which
you'll use daily as a React 18+ developer. And for the one time in your career
when you need to pull it out, you'll know precisely the right tool for the job.

What is `useLayoutEffect`?

As every good developer pretends to do before Googling, let's turn to the
docs.

The first thing we see on the page for useLayoutEffect is a bright orange
warning telling us not to use useLayoutEffect.

Got it.

Reading on, we find the following description:

useLayoutEffect is a version of useEffect that fires before the browser repaints the screen.

Sweet.

If you understand useEffect, this is a pretty straightforward explanation of
useLayoutEffect. However, if you've found yourself here and don't have a firm
grasp on useEffect, I'd recommend reading up on
useEffect and
revisiting. And since you didn't take my advice, let's quickly recap
useEffect.

`useEffect` Recap

useEffect calls an anonymous function after the values in its dependency array
have changed. It is asynchronous and non-blocking. It runs after the browser has
painted the screen and can optionally return a "clean-up" function. Essentially,
useEffect is all the old crusty component lifecycle methods rolled up into one
tidy hook.

useEffect's primary purpose is to asynchronously run
side effects
without blocking
JavaScript's Single Thread,
offering a more performant and responsive application resulting in a more
seamless User Experience.

In plain English, your React App won't wait on useEffect to finish doing its
thing before rendering the page. Your page will render while the useEffect
will run alongside the browser paint, and if your useEffect affects the UI, it
will only rerender what is needed. Fetching data from an API and updating state
is one of the most common use cases for useEffect.

So how does this compare to useLayoutEffect?

`useEffect` vs. `useLayoutEffect`

useLayoutEffect's signature is identical, but it is synchronous, blocking, and
runs before the browser paints. So these two are kind of exactly the same but
kind of exactly the opposite.

useEffect(() => {
  // asynchronous, non-blocking, runs after the browser paints
}, [dependencyArray]);

useLayoutEffect(() => {
  // synchronous, blocking, runs before the browser paints
}, [dependencyArray]);

Starter Code

Let's finally dive into the code.

In App.js, you'll see our entire app that aims to simulate a Super Exciting
Live Stream with a chat functionality on the sidebar.

On lines 15 and 16, we're simply initializing a ref called afterChatRef and
a state called messages.

After our imports, we have a setInterval function that counts to a billion
every two milliseconds. React is getting better and better at outsmarting our
clunky code, so this is purely a way to slow down the application. And the
comment is just asking es-lint to cool it with the unused vars warning since
we're not doing anything with sum after incrementing it.

setInterval(() => {
  let sum = 0;
  for (let i = 0; i < 1e9; i++) {
    // eslint-disable-next-line no-unused-vars
    sum += i;
  }
}, 2);

Next, we'll look at our getMessages function on line 19, which gets our data
from a dummy API and sets that data to the messages state.

const getMessages = async () => {
  const res = await axios.get('https://dummyjson.com/users?limit=100');
  setMessages(res.data.users);
};

On line 24, we have a useEffect with an empty dependency array that calls our
function. So the component mounts, the browser paints the virtual DOM, then,
when our useEffect runs, it updates messages which rerenders the page and
causes the DOM to repaint.

useEffect(() => {
  getMessages();
}, []);

Next, we have another useEffect on line 28, whose dependency array contains
messages. Since this hook depends on the value of messages, it doesn't
trigger until the messages object changes. After that happens, this
useEffect scrolls the afterChatRef into view. Practically speaking, it takes
the user to the bottom of the chat. There is no functionality to add new
messages, but as you can imagine, when the user adds a message, state changes,
and our useEffect scrolls us to the bottom.

useEffect(() => {
  afterChatRef.current?.scrollIntoView();
}, [messages]);

Nothing exciting in the JSX. Our "stream" is on the left, and we're
conditionally rendering the messages in a container on the right.

So What's the Problem?

Admittedly, were it not for my function counting to a billion every two
milliseconds, we would use useEffect and not notice the issue. If your machine
is significantly faster than mine, you still may not notice the problem. If
that's the case, open your dev tools (shame on you for not already having them
open), click the Performance tab, click CPU No throttling, and set it to
4x slowdown or even 6x slowdown, depending on how much richer you are than
me.

Refresh the page. Nice and slow.

See how the chat loads and hangs at the top for a moment before snapping to the
bottom? Let's reduce the for loop to 1e5 (100,000) instead of 1e9, save,
and refresh. This is closer to how it may look out in the wild. This flicker is
that "obscenity" I was talking about earlier.

Let's refer back to the React doc's tooltip example to see the root issue
they're trying to solve.

You don’t want the user to see the tooltip moving. Call useLayoutEffect to perform the layout measurements before the browser repaints the screen.

You don't want the user to see the tooltip moving. Or, say, to see the chat
flickering before snapping to the bottom?

Implementing `useLayoutEffect`

This refactor will be significantly less work than previous articles. All we
need to do is import useLayoutEffect from 'react'.

import { useState, useEffect, useLayoutEffect, useRef } from 'react';

And replace our useEffect on line 28 with useLayoutEffect, leaving the
useEffect on line 24 undisturbed.

useLayoutEffect(() => {
  afterChatRef.current?.scrollIntoView();
}, [messages]);

Now, when we save and refresh, voila! Our chat no longer flickers at the top
before scrolling to the bottom.

To demonstrate further, change our arbitrary loop back to 1e9 and throttle
your browser if needed. Refresh.

While painfully slow, you can see the DOM doesn't paint the chat section until
after the useLayoutEffect has scrolled us to the bottom.

Some Cautions

No flicker. So why not always use useLayoutEffect over useEffect? Well, it's
essential to understand what precisely is going on and why we should heed
React's enormous orange warning.

Remember, useLayoutEffect is
synchronous
and blocking. Synchronous means it runs from the top down line-by-line, and
blocking means it is a resource hog and occupies the entire thread until the
function has completed. The docs recommend useEffect over useLayoutEffect
for these very reasons. Because useEffect is asynchronous and non-blocking, it
is the right hook for the job most of the time.

Our chat no longer flickers because, after the value of messages changes,
we're blocking the browser from painting the DOM until the useLayoutEffect
scrolls the chat to the bottom. Because of this blocking behavior, we should
only implement useLayoutEffect when we notice the need. If we go around
useLayoutEffect-ing all over the place, we'll unnecessarily bog down our app
and may as well be writing in vanilla JavaScript.

We should approach useLayoutEffect with the same opt-in mentality as
useCallback or useMemo. Only use it when you notice the need.

Preemptively optimizing our app will often introduce bugs and complicate the
codebase with little benefit. In general, if you don't know whether you should
use useLayoutEffect, you probably shouldn't.

Conclusions

useLayoutEffect is a nifty little hook. Being able to discuss it intelligently
might impress some fellow nerds at a cocktail party and maybe even a hiring
manager or two. Truthfully, you won't use it very often, but if you do, it's
important to acknowledge the tradeoffs and consciously sacrifice.

Just remember, you'll know it when you see it.

I’m always looking for new friends and colleagues. If you found this article helpful and would like to connect, you can find me at any of my homes on the web.
GitHub | Twitter | LinkedIn | Website

Resources

useRef – Demystifying React Hooks (Pt. 3)

Austin Ryan Taylor — Thu, 16 Feb 2023 21:42:33 +0000

In this article, we will discuss some common use cases for React's useRef Hook.

Getting Started

We will use the Profiler from the React Dev Tools to see how our components are rendering. If you don't have the React Dev Tools and plan to follow along, you'll need to pause and download it now.

If you'd like to follow along in your local IDE, you can find the GitHub Repo here.

fork and clone
cd client
npm i
npm start

Starter Code

As always, we'll start with a tour of our codebase. This time, App.js is a simulated Login Form.

We have initialFormValues, an object with a blank email and password, which we use to initialize our formValues state.

const initialFormValues = {
  email: '',
  password: '',
};

const [formValues, setFormValues] = useState(initialFormValues);

We then have boilerplate handleChange and handleSubmit functions, and the handleSubmit logs formValues to the console.

const handleChange = (e) => {
  setFormValues({
    ...formValues,
    [e.target.name]: e.target.value,
  });
};

const handleSubmit = (e) => {
  e.preventDefault();
  console.log(formValues);
};

Finally, our JSX renders the form and assigns the appropriate onChange and onSubmit attributes.

return (
  <main>
    <section>
      <form onSubmit={handleSubmit}>
        <label htmlFor='email'>Email</label>
        <input
          type='email'
          name='email'
          placeholder='Email'
          onChange={handleChange}
        />
        <label htmlFor='password'>Password</label>
        <input
          type='password'
          name='password'
          placeholder='Password'
          onChange={handleChange}
        />
        <button type='submit'>Login</button>
      </form>
    </section>
  </main>
);

What's the Problem?

So you may be asking, "What's wrong with this component? It works as expected, and I've written forms like this countless times."

So have I, friend. So have I.

Open your React Dev Tools and click the Settings cog. Next, click the 'Profiler' tab and tick on the option, "Record why each component rendered while profiling."

Now open the Profiler tab, and you will see a blue dot in the upper left corner. Click it to start profiling. Next, type in the inputs and click the (now red) dot to stop profiling.

Click the App component on the left inside the Profiler tab, and you'll see a list of all the renders. Notice the Profiler provides the same reason for each:

Why did this render?

Hook 1 changed

The component re-rendered on every keystroke.

Minimizing Renders

If our form's sole purpose is to submit the inputs elsewhere, then we don't need the component to re-render in real time. We don't care what the value is while the user is typing. We only care about the value when the form is submitted.

This may seem harmless in a small application, but it can significantly impact our application as it scales. And part of being a good React developer is being mindful of the performance of our applications by minimizing renders.

Enter `useRef`

In the broadest sense, the useRef Hook creates a mutable variable that persists between renders. It provides the ability to store a value we can access outside the render cycle.

Let's try using useRef to store our render count.

We'll start by importing useRef in our current import.

import { useState, useRef } from 'react';

We will initialize renders with useRef and set it to 0. When we initialize a ref, the Hook creates an object with a current property. current is the property we must use to update the ref's value.

const rendersRef = useRef(0);

We'll use a useEffect Hook without the dependency array to increment renders every time the component renders. And take note that we change the value of a ref, unlike useState, we can do so directly.

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

...

useEffect(() => {
  rendersRef.current++;
});

Let's render renders in our JSX.

<section>
  <h3>Render Count: {rendersRef.current}</h3>
  <form onSubmit={handleSubmit}>

When we type in the input, we see our render count incrementing in real-time. Neat, I guess, but not particularly useful.

From the React Docs:

useRef returns a ref object with a single current property initially set to the initial value you provided. On the next renders, useRef will return the same object. You can change its current property to store information and read it later. This might remind you of state, but there is an important difference. Changing a ref does not trigger a re-render. This means refs are perfect for storing information that doesn’t affect the visual output of your component.

...information that doesn’t affect the visual output of your component.

Kind of like a login form?

Refactoring Our Form with `useRef`

Let's start by creating two new refs to store our email and password values and initialize them as null.

const emailRef = useRef(null);
const passwordRef = useRef(null);

When using the useRef Hook to reference a DOM element, associating it is incredibly simple. All we need to do is add a ref attribute to the element and provide it our ref variable as its value.

<input
  type='email'
  name='email'
  placeholder='Email'
  ref={emailRef}
  onChange={handleChange}
  />

  ...

<input
  type='password'
  name='password'
  placeholder='Password'
  ref={passwordRef}
  onChange={handleChange}
  />

Next, we need to refactor our handleSubmit function. Instead of logging formValues, we'll create an object, setting the values as each ref's current property.

const handleSubmit = (e) => {
  e.preventDefault();
  console.log({
    email: emailRef.current.value
    password: passwordRef.current.value
    });
};

Type in the inputs and click Login. You should see your object logged properly while the render count remains 0. The Profiler also finds no activity. Changing the value of our refs did not cause the component to re-render.

With that working, we no longer need the following:

email onChange attribute
password onChange attribute
handleChange function
formValues state
initialFormValues object
useState import

Though we aren't directly using it anymore, we should keep the name attributes for accessibility.

Test the application again. We removed a lot of code, but it still works as expected!

`useRef` vs. `useState`

This accurately demonstrates the point raised in the React Docs: updating useRef does not trigger a re-render, which is probably the most significant difference between useRef and useState.

In addition, you'll notice that when we updated the current property on our ref, we did so directly. Never do this with useState. Instead, you must always use the setter function if you wish your UI to react to the change. You can read about this behavior here.

Yes, I know. We literally just used useRef to affect a change in the DOM. In my defense, try to use useState to track your render count and include itself in that count. If you can figure out a way without causing an infinite re-render, please reach out. I'd like you to teach me!

One Last Use Case

Before concluding this article, I’d like to address what I think is the simplest common use case for useRef. Let’s start by moving our render count below the section tag containing our form. We’ll put it in its own section tag.

<section>
  <h3>Render Count: {rendersRef.current}</h3>
</section>

Next, we will create a formRef for our form and assign it accordingly. Let’s add a button with the text, Scroll to Render Count.

const formRef = useRef(null);
...
<section ref={formSectionRef}>
  <form onSubmit={handleSubmit}>
...
  </form>
<button>Scroll to Render Count</button>

Then we will initialize renderCountSectionRef, assign it to our render count container, and add a button with the text Scroll to Form.

const renderCountSectionRef = useRef(null);
...
<section ref={renderCountSectionRef}>
  <h3>Render Count: {rendersRef.current}</h3>
  <button>Scroll to Form</button>
</section>

Let’s create a new function called scrollToElement that expects a ref as a parameter and scrolls us to said ref.

const scrollToElement = (ref) => {
  ref.current.scrollIntoView({ behavior: 'smooth' });
};

Now, we will set the onClick property to scrollToElement with the appropriate ref as its argument.

Please note that using inline functions will make for a less performant app, but that refactor would require more custom logic and is outside the scope of this article.

<button
  onClick={() => {
    scrollToElement(renderCountSectionRef);
  }}
>
  Scroll to Render Count
</button>

...

<button
  onClick={() => {
    scrollToElement(formSectionRef);
  }}
>
  Scroll to Form
</button>

Now, when we click the buttons, we scroll about the page! This feels a lot like a Scroll To Top or Jump to Recipe button, doesn't it?

Since scrolling to a specific element doesn't demand a re-render, it is a much better use case for useRef than useState.

A Caution

After realizing that we can affect changes on DOM Elements directly with useRef, it may be tempting to use this method as an analog to querySelector or getElementBy—.

This is an anti-pattern and should be avoided if possible. It can cause your UI to fall out of sync with your state and, in a larger application, can have an unforeseen ripple effect. These bugs will be challenging to track down.

Conclusions

In this article, we discussed the functionality of useRef, how it persists through renders, and how, unlike useState, it does not cause re-renders. We also explored one of the most common uses of useRef: to navigate our user to different DOM elements.

I’m always looking for new friends and colleagues. If you found this article helpful and would like to connect, you can find me at any of my homes on the web.
GitHub | Twitter | LinkedIn | Website

Resources

useMemo – Demystifying React Hooks (Pt. 2)

Austin Ryan Taylor — Thu, 16 Feb 2023 21:37:45 +0000

In this article, we will explore when and how to use React's useMemo Hook to increase your app's performance.

Getting Started

Buckle up and strap in. This article is on the heavier side for both theory and length.

If you'd like to follow along in your local IDE, you can find the GitHub Repo here.

fork and clone
cd client
npm i
npm start

Starter Code

We'll begin with a quick overview of our starter code. In App.js, you'll find a function name "jacobsthal," two pieces of state, and a variable named "calculation". Notice we wrapped jacobsthal in a useCallback Hook, and calculation is the returned value from calling jacobsthal.

The JSX renders both inputs and their respective values. If you need a refresher on what service the useCallback Hook provides, I'd suggest you pause here and give my useCallback article a quick read.

import './App.css';
import { useState, useCallback } from 'react';

function App() {
  const [number, setNumber] = useState('');
  const [input, setInput] = useState('');

  const jacobsthal = useCallback((n) => {
    if (n < 2) return n;
    return jacobsthal(n - 1) + 2 * jacobsthal(n - 2);
  }, []);

  const calculation = jacobsthal(number);

  return (
    <div>
      <main>
        <section>
          <div className='user-input'>
            <input
              type='text'
              value={number}
              placeholder='desired index'
              onChange={(e) => {
                setNumber(e.target.value);
              }}
            />
          </div>
          <div className='result'>{calculation || 0}</div>
        </section>
        <section>
          <div className='user-input'>
            <input
              type='text'
              value={input}
              placeholder='user input'
              onChange={(e) => {
                setInput(e.target.value);
              }}
            />
          </div>
          <div className='result'>{input || '--'}</div>
        </section>
      </main>
    </div>
  );
}

export default App;

Our jacobsthal function is a simple, recursive function that returns the Jacobsthal Number at a given index. The specifics of the code and Jacobsthal Number don't matter for useMemo. All we care about is that it's defined within our component, hence the implementation of useCallback, and that it's computationally expensive.

If we provide a small value to the number input, our React app behaves as expected, snappily rendering the result. However, as we increase the value of our input, while the app still provides the desired output, it takes increasingly longer to render.

Why is This Happening?

Thirty-five will be our test case because it is slow enough to be annoying but still testable. So we'll type 35 and wait for the output to calculate.

Now start typing into the second input. See how slow it is to render? That's because when the input changed, the entire component re-rendered, and our expensive function recalculated the output before re-rendering, even though our output didn't change.

This is obviously a problem.

A Quick Aside: Junior Developers make this mistake far too often. You don't always need useState for your forms. I'll even propose that you **usually don't**. If no part of your application needs to see the real-time value, like when submitting a form to an API, you should be using useRef instead. We will get into how and why in a later article.

So with the stage set and the curtains drawn, how do we resolve the issue at hand?

Memoization

Memoization is a Programming technique that stores the results of a function call, so the next time you call that function, it doesn't have to recalculate the output. Instead, it can return the stored result, saving time complexity with recursive functions.

That's all you need to know for now, but if you'd like a more in-depth explanation, check out this Memoization in JavaScript article by GeeksforGeeks. And at the end of this article, we will refactor our jacobsthal function to implement proper JavaScript memoization.

`useMemo` vs. `useCallback`

To sum it up, useCallback stores the definition of the function, so it doesn't unnecessarily redefine every render. useCallback creates referential equality between instances of the function across renders.

Similarly, useMemo stores the result of the function call, so it doesn't unnecessarily recalculate every render. useMemo creates referential equality between instances of the value across renders.

You can already see how this is helpful and leads directly to the primary purpose of useMemeo. In short, the aptly named useMemo Hook is React's built-in memoization tool.

`useMemo` in Action

Let's write some code!

We'll start by importing useMemo from 'react'.

import { useState, useCallback, useMemo } from 'react';

`useMemo` Syntax

You guessed it, useMemo has a similar syntactical skeleton to both useEffect and useCallback: an anonymous callback function with a dependency array that tracks a variable to tell our Hook when to trigger.

useEffect = (() => {}, []);
useCallback = (() => {}, []);
useMemo = (() => {}, []);

As in our useCallback example, we want to cache what's returned from this Hook. So we will assign our calculation variable to the return value of useMemo, wrapping our function call in an anonymous callback.

Remember to return the result of your function call so it is accessible by useMemo!

const calculation = useMemo(() => {
  return jacobsthal(number);
}, []);

After we save, we'll notice a familiar warning from React. Our Hook is missing a dependency.

WARNING in [eslint]
src/App.js
  Line 11:6:  React Hook useMemo has a missing dependency: 'number'. Either include it or remove the dependency array  react-Hooks/exhaustive-deps

webpack compiled with 1 warning

Before blindly obeying React's warnings, let's first think through the purpose of this dependency array and the functionality it extends to our application.

The intent of dependency arrays with React Hooks is to trigger our Hook more intentionally and specifically. When the value of the variable being tracked changes, the Hook knows it's time to do its thing.

In our specific case, when number changes, we want our jacobsthal function to recalculate the result.

So let's add number to our dependency array.

const calculation = useMemo(() => {
  return jacobsthal(number);
}, [number]);

Now that we've memoized our function, let's test it out. We'll start by typing 35. Our calculation still takes time because our jacobsthal function is still computationally expensive. But now, when we type in the second input, our React app is again snappy and responsive. It's no longer recalculating our jacobsthal output because number has not changed.

Conclusion (kind of)

Because we memoized the results of our function, we've created referential equality and eliminated any unnecessary renders, making our React app more performant.

If you only came here for the React piece, thanks so much for reading, and look out for the useRef article next!

But what to do about our computationally expensive jacobsthal function? Time to refactor.

We begin by creating a previousValues parameter with a default value of an empty array. This will be our cache that we will later pass to our recursive sequence. Doing so will spare our recursive sequence from working overtime.

export const jacobsthal = (n, previousValues = []) => {
  if (n < 2) {
    return n;
  }
  return jacobsthal(n - 1) + 2 * jacobsthal(n - 2);
};

Next, inside our code block, we'll create a results variable. We will later reassign the value, so we'll need to use our let keyword.

export const jacobsthal = (n, previousValues = []) => {
  let result;
  if (n < 2) {
    return n;
  }
  return jacobsthal(n - 1) + 2 * jacobsthal(n - 2);
};

Instead of returning our computations directly, we'll explicitly wrap our recursive sequence in an else block and assign our return options to result.

export const jacobsthal = (n, previousValues = []) => {
  let result;
  if (n < 2) {
    result = n;
  } else {
    result = jacobsthal(n - 1) + 2 * jacobsthal(n - 2);
  }
};

Now, after our conditionals have evaluated and assigned a value to result, we set previousValues at index n equal to our current result, then return result, thus caching this value and making it accessible as a return.

export const jacobsthal = (n, previousValues = []) => {
  let result;
  if (n < 2) {
    result = n;
  } else {
    result = jacobsthal(n - 1) + 2 * jacobsthal(n - 2);
  }
  previousValues[n] = result;
  return result;
};

Next, the first thing our function should do is check to see if previousValues at index n exists. If it does, we return it.

export const jacobsthal = (n, previousValues = []) => {
  if (previousValues[n]) {
    return previousValues[n];
  }
  let result;
  if (n < 2) {
    result = n;
  } else {
    result = jacobsthal(n - 1) + 2 * jacobsthal(n - 2);
  }
  previousValues[n] = result;
  return result;
};

Lastly, we'll pass previousValues as an argument to our recursive sequence.

export const jacobsthal = (n, previousValues = []) => {
  if (previousValues[n]) {
    return previousValues[n];
  }
  let result;
  if (n < 2) {
    result = n;
  } else {
    result = jacobsthal(n - 1, previousValues) + 2 * jacobsthal(n - 2, previousValues);
  }
  previousValues[n] = result;
  return result;
};

Conclusions (for real this time)

Whew. We can now test our newly (and thoroughly) memoized component. Try 35 again. Pretty snappy, huh? So snappy, in fact, that if we enter 1026 as our input, it's still responsive. Even calculating 'Infinity' doesn't crash our app. And yes, useMemo is still doing its thing.

There is no lag in our other input.

If you'd like to dive deeper with useMemo, you can learn more in the official React docs.

I’m always looking for new friends and colleagues. If you found this article helpful and would like to connect, you can find me at any of my homes on the web.
GitHub | Twitter | LinkedIn | Website

Resources

useCallback – Demystifying React Hooks (Pt. 1)

Austin Ryan Taylor — Thu, 16 Feb 2023 21:31:24 +0000

In this article, we will explore when and how to use React’s useCallback hook and a mistake made by most Junior Developers.

If you'd like to close this down and run it locally, the repo can be found here

Getting Started

fork and clone
cd client
npm i
npm start

Referential Equality

Referential Equality is a foundational concept in both JavaScript and Computer Science as a whole. So let's start with a demonstration of it in action.

You can simply read along or run referentialEquality.js to observe the output.

console.log(1 === 1);
// prints true

When evaluating whether the integer 1 is strictly equal to the integer 1, the console prints true. This is because, well... the integer 1 is strictly equal to the integer 1.

We see the same result when evaluating two strings.

console.log('Referential Equality' === 'Referential Equality');
// prints true

Obviously, this will always be the case for two primitive data types of the same value.

Now, what about data structures? For example, two object literals with the same key/value pairs? What about empty object literals?

console.log({ a: 1 } === { a: 1 });
// prints false

Why would this print false? When comparing whether these two object literals are strictly equal, JavaScript uses their respective memory addresses.

In other words, these two objects may contain the same values, but they're not referencing the same object. They look the same but occupy two different spaces in memory.

The same applies whether you're comparing two object literals, two array literals, or two functions!

console.log({} === {});
// prints false

console.log([1, 2, 3] === [1, 2, 3]);
// prints false

console.log([] === []);
// prints false

To demonstrate this further, we will define a function func, which returns an anonymous function that, in turn, returns something else (like a JSX element).

const func = () => {
  return () => 'This is a pretend component.';
};

We will then assign two different functions, firstRender and secondRender, equal to the value returned by func.

const firstRender = func();

const secondRender = func();

Think of func as your React functional component, while firstRender is a function _inside_ of it on the first render, and secondRender is a function _inside_ of it on the second render.

Even though firstRender and secondRender look the same, return the same value, and are even assigned their value from the same definition, they do not have referrential equality. As a result, every time the parent component renders, it redefines this function.

console.log(firstRender === secondRender);
// false

Unfortunately, in JavaScript, it isn’t easy to print these memory addresses like in Python, but for a slightly more in-depth explanation of reference vs. value, take a look atthis article.

This topic can get dense, and you don't need to teach a class on it tonight. So for now, just remember:

primitive data type === primitive data type
data structure !== data structure.

With referential equality out of the way, let's dive into our React code and see why this is relevant.

Starter Code

Start by looking through the provided code, then open your dev tools. We're going to be using the browser's console in a bit.

After we spin up our app, open the BookDetails.jsx component and re-save. The first thing we may notice in our React dev server is a common WARNING that young developers tend to ignore. As you hit the workforce and start writing code for production, your linters will be even more strict than what’s built into create-react-app. WARNINGS will turn to ERRORS, and some linter rules won't even allow you to push without addressing these ERRORS.

And brace yourself; most linters won't allow console.logs in your code. So the earlier you learn the proper way, the better. So rather than ignore it, let’s figure out how to treat it.

WARNING in [eslint]
src/components/BookDetails.jsx
  Line 18:6:  React Hook useEffect has a missing dependency: 'getBookDetails'. Either include it or remove the dependency array  react-hooks/exhaustive-deps

webpack compiled with 1 warning

NOTE: you may first need to re-save BookDetails.jsx to create this WARNING

If we dig into the React Docs, we can decode the semi-confusing proposed solutions to this WARNING as follows:

Take a moment to think through the consequences of each option.

Include the function definition inside of theuseEffect

We cannot call this function elsewhere unless we redefine it.

Remove the dependency array.

This will trigger the useEffect every time the state or props change, typically causing an infinite re-render, and in our case, it could overload our API with infinite requests.

Remove the function call from the useEffect.

The function won't get called.

Include the function in the dependency array.

The first time the component renders, it will define our function, which will trigger the useEffect, which will cause the component to re-render, which will redefine the function, which will trigger the useEffect, which will cause the component to re-render, which will redefine the function...

So ...what's a developer to do?

The simplest and preferred solution would be to 'include it,' that is, move the getBookDetails function definition inside the useEffect. This adheres to an Object-Oriented Programming principal known as Encapsulation.

But let’s say we know we need to call the function elsewhere. Should we redefine it later? That’s not very DRY of us.

Let’s change our dependency array to include our function reference. Your useEffect should now look like this.

useEffect(() => {
  getBookDetails();
}, [getBookDetails]);

And getBookDetails remains defined above the useEffect.

const getBookDetails = async () => {
  const res = await axios.get(`${BASE_URL}/${id}`);
  setBook(res.data);
  console.log(res.data);
};

Now we have a new WARNING:

WARNING in [eslint]
src/components/BookDetails.jsx
  Line 10:9:  The 'getBookDetails' function makes the dependencies of useEffect Hook (at line 18) change on every render. Move it inside the useEffect callback. Alternatively, wrap the definition of 'getBookDetails' in its own useCallback() Hook  react-hooks/exhaustive-deps

webpack compiled with 1 warning

Enter the `useCallback` Hook

In short, the useCallback hook allows you to cache, or ‘memoize,’ a function between re-renders of your component. It performs a similar task to useMemo, the nuances of which we will get into in a different article.

If the nitty-gritty of this interests you, you can read more about it in the React docs.

Please notice their warning:

You should only rely on useCallback as a performance optimization. If your code doesn’t work without it, find the underlying problem and fix it first. Then you may add useCallback to improve performance.

`useCallback` Syntax

useCallback syntax is very similar to the useEffect syntax, which we already know. Look at the skeletons of each.

useEffect(() => {}, []);

useCallback(() => {}, []);

The slight difference is with useEffect, we tell the anonymous function to execute our function while with useCallback, we assign the return value to a reference to be called elsewhere.

First, we will import useCallback from 'react'. Rather than adding a new line, it’s best to destructure it along with our other imports.

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

Now we can assign getBookDetails to the value returned from a useCallback function call.

const getBookDetails = useCallback();

Then we add all the syntax for useCallback. Remember your dependency array!

const getBookDetails = useCallback(() => {}, []);

In our example, we need async before our parameters.

const getBookDetails = useCallback(async () => {}, []);

And finally, we add the logic of our function into the code block.

const getBookDetails = useCallback(async () => {
  const res = await axios.get(`${BASE_URL}/${id}`);
  setBook(res.data);
  console.log(res.data);
}, []);

Once we save, we get… another WARNING.

WARNING in [eslint]
src/components/BookDetails.jsx
  Line 14:6:  React Hook useCallback has a missing dependency: 'id'. Either include it or remove the dependency array  react-hooks/exhaustive-deps

webpack compiled with 1 warning

Let's think through this for a moment.

Why should our dependency array track the id variable?

If the value of id changes, `getBookDetails` needs to hit a different endpoint, so React should redefine it.

After we add id to our dependency array, our finished getBookDetails and useEffect functions should look like this. Look closely at the differences between the way we implement the two hooks.

const getBookDetails = useCallback(async () => {
  const res = await axios.get(`${BASE_URL}/${id}`);
  setBook(res.data);
  console.log(res.data);
}, [id]);

useEffect(() => {
  getBookDetails();
}, [getBookDetails]);

And finally, that’s it! We see green in our React dev server. A happy linter is a happy Senior Developer. And a happy Senior Developer is a happy you!

I’m always looking for new friends and colleagues. If you found this article helpful and would like to connect, you can find me at any of my homes on the web.
GitHub | Twitter | LinkedIn | Website

Forem: Austin Ryan Taylor

useReducer – Demystifying React Hooks (Pt. 5)

Getting Started

useReducer

Why Bother?

Starter Code

A Simple Refactor

useReducer Signature

Refactoring Counter

Refactoring darkMode

Refactor input

Refactoring Our action Object

The Tradeoffs

Conclusions

Resources

useLayoutEffect – Demystifying React Hooks (Pt. 4)

Getting Started

Creating the Problem

What is useLayoutEffect?

useEffect Recap

useEffect vs. useLayoutEffect

Starter Code

So What's the Problem?

Implementing useLayoutEffect

Some Cautions

Conclusions

Resources

useRef – Demystifying React Hooks (Pt. 3)

Getting Started

Starter Code

What's the Problem?

Minimizing Renders

Enter useRef

Refactoring Our Form with useRef

useRef vs. useState

One Last Use Case

A Caution

Conclusions

Resources

useMemo – Demystifying React Hooks (Pt. 2)

Getting Started

Starter Code

Why is This Happening?

Memoization

useMemo vs. useCallback

useMemo in Action

useMemo Syntax

Conclusion (kind of)

Conclusions (for real this time)

Resources

useCallback – Demystifying React Hooks (Pt. 1)

Getting Started

Referential Equality

Starter Code

Enter the useCallback Hook

useCallback Syntax

Resources

`useReducer`

`useReducer` Signature

Refactor `input`

Refactoring Our `action` Object

What is `useLayoutEffect`?

`useEffect` Recap

`useEffect` vs. `useLayoutEffect`

Implementing `useLayoutEffect`

Enter `useRef`

Refactoring Our Form with `useRef`

`useRef` vs. `useState`

`useMemo` vs. `useCallback`

`useMemo` in Action

`useMemo` Syntax

Enter the `useCallback` Hook

`useCallback` Syntax