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

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.

So, 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:

A Simple Refactor

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

Next, we’ll initialize our state with useReducer.

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 count

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.

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.

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.

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.

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

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.

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

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.

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

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.

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

Refactoring 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.

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

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

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

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.

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

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

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

• useReducer
• useState
• Flux
• Redux
• ES6 Spread Operator

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 follow along in your local IDE, you can find the GitHub 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 it.

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. However, if you've found yourself here and don't have a firm grasp on useEffect, I'd recommend reading up on theat and revisiting this article. 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 the in-browser 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 painting the DOM. Your virtual DOM will render and browser will paint while useEffect runs alongside that process, and if your useEffect affects the UI, it will only repaint 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 exactly the same but exactly the opposite.

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.

On line 19, getMessages gets our data from a dummy API and sets that data to the messages state.

On line 24, we have a useEffect with an empty dependency array that calls our getMessages function. So the component mounts, the virtual DOM is rendered and painted to the real DOM, then, when our useEffect runs, it updates messages which rerenders the virtual DOM, React compares the diff and causes the real DOM to repaint.

There’s another useEffect on line 28, whose dependency array contains messages. Since this hook depends on the value of messages, it doesn't trigger until messages changes. When called, 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.

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 sandbagging our app, we would use useEffect like normal 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'.

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

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.

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.

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. These are actually both standard function behavior JavaScrip in-browser. Synchronous means it runs from the top down line-by-line, and blocking means it is a resource hog that won’t return until completed.

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.

This is why the docs recommend useEffect or useLayoutEffect. We should approach useLayoutEffect with the same opt-in mentality as useCallback or useMemo. Only implement it after 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 implement useLayoutEffect, you probably shouldn't.

Conclusions

useLayoutEffect is a nifty little hook, and truthfully, you won’t use it very often. But if you do, it’s important to acknowledge the tradeoffs and make conscious sacrifices. Don’t go preoptimizing willy-nilly. As we used to say in the film industry, “Do nothing. Stay ahead.”

And hey, being able to discuss useLayoutEffect intelligently might impress some fellow React nerds in your favorite comments section and even a Hiring Manager or two. But let’s circle back to the question that started this all. “When should I use useLayoutEffect?”

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

• GitHub Repo
• useLayoutEffect
• useEffect
• Side Effects
• Why JavaScript is a Single-Thread Language That Can Be Non-Blocking
• Synchronous vs Asynchronous in JavaScript

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.

• Chrome React Dev Tools
• Firefox React Dev Tools

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.

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

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

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.

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.

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.

Let’s render renders in our JSX.

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.

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.

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.

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 to know.

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.

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.

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

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

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.

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

• GitHub Repo
• useRef
• useState
• React Profiler
• React Dev Tools for Chrome
• React Dev Tools for Firefox

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

TL;DR

If you’re here solely to understand when to (and not to) use useMemeoand don’t want to work through the examples, I’ll spare you. According to the React Docs, much like useCallback, useMemo is an opt-in performance enhancer Hook used to create referential equality for function results. The three most common use cases are:

1. if the calculation causes noticeable slowdown in other parts of your app
2. if you’re passing the calculation as a prop to a child component
3. if the calculation is used as a dependency in a Hook

If none of those conditions is being met, you’re likely wasting time, lines, and sacrificing readability (and memory) by proactively “optimizing” your app.

With that out of the way, Let’s get started.

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. Otherwise, you can reference the code snippets, though you will miss out on the performance comparisons.

• 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 named "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.

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 our 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 jacobsthal 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 on 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 on 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 useMemo. 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'.

useMemo Syntax

You guessed it, useMemo has a similar syntactical skeleton to both useEffect and useCallback: an anonymous callback with a dependency array.

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!

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

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.

Now that we’ve memoized our function, let’s test it out. We’ll start by inputting 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.

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.

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

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.

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

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

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

• useMemo
• useCallback
• Recursion
• Time Complexity
• Memoization
• Jacobsthal Number

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

TL;DR

If you’re here for a quick definition and don’t want to traverse through the examples, I’ll spare you. According to the React Docs,useCallback is an opt-in performance enhancer Hook used to create referential equality for function definitions. The two most common use cases are:

1. when you’re passing a function as a prop to a child component
2. if the function is used as a dependency in a Hook.

If neither of those two conditions is being met, you’re likely wasting time, lines, and sacrificing readability (and memory) by proactively “optimizing” your app.

With that out of the way, Let’s get started.

Getting Started

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

• 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.

I’ve embedded screenshots throughout the article for ease of use on mobile. If you’re on desktop and have cloned it down, run referentialEquality.js to observe the output or just play with the JSFiddle snippet embedded below.

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.

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?

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!

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).

We will then assign two different functions, firstRender and secondRender, equal to the value returned by 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 return the same value and are assigned from the same definition, they do not have referential equality. As a result, every time the component renders, it redefines this function.

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 at this article from freeCodeCamp.

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

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 linters won’t allow you to push before you address these ERRORS.

So rather than ignore it, let’s figure out how to treat it.

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:

1. Include the function definition inside of the useEffect .

• We cannot call this function elsewhere unless we redefine it.

2. Remove the dependency array.

• This will trigger the useEffect every time state or props change, sometimes causing an infinite re-render. And in our case, since we’re calling our state setter function after an API call, it could overload our API with infinite endpoint requests.

3. Remove the function call from the useEffect.

• The function won’t get called.

4. 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.

And getBookDetails remains defined above the useEffect.

Now we have a new 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 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’s syntax is very similar to the useEffect’s syntax which we already know. Look at the skeletons of each.

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.

Using useCallback

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

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

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

In our example, we need async before our parameters.

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

Once we save, we get… another WARNING .

Why should our dependency array track the id variable?

Let’s think through this.

• If the value of id changes, getBookDetails needs to hit a different endpoint, so React should redefine it. The definition of getBookDetails literally depends on the value of id .

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.

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

Resources

• Referential Equality
• JavaScript Primitive Data Types vs. Data Structures
• Encapsulation
• useCallback
• React Docs