DEV Community: Peter Shershov

React: Lessons from the Trenches - useEffect x Infinity

Peter Shershov — Thu, 23 Mar 2023 13:21:46 +0000

Hey! My name is Peter and I’m a software team-lead, working on Codux by Wix.com.

I’ve been building user interfaces with React for more than 6 years and have made tons of mistakes during this time. From memoizing almost everything in my component to drilling props like I’m looking for oil — I fell into every trap. I’ll try to break down a couple of issues I’ve dealt with and hopefully, it’ll help you jump over pitfalls in the future. Some articles in this series will address bad practices and design concerns while others focus on specific bugs in special use cases.

Let’s start with a prevalent one, updating a state within useEffect can cause an infinite loop by re-rendering the component to infinity.

What we see above is a warning (“Maximum update depth exceeded”) indicating that there’s an operation occurring too many times, one after the other.

This can happen in several scenarios.



const [superheroes, setSuperheroes] = useState([]);

const updateSuperheroes = () => {
   const newSuperhero = generateSuperhero();
   setSuperheroes([...superheroes, newSuperhero]);
};

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

Consider the example above.
First of all, we know that every state update triggers a re-render, meaning that the code written inside the component function gets executed. We also know that useEffect executes when one of two conditions is met after a render:

A component is mounted
One of the dependencies (declared in useEffect’s dependency array) has changed.

Keep in mind that useEffect’s dependency array should reflect the usage. Omitting a dependency that is used inside the useEffect can cause stale data issues, while including a dependency that does not impact the effect can cause unnecessary re-renders.

With these in mind, we can start debugging the code above.
We can see that updateSuperheroes() is executed inside a useEffect, which requires us to declare it as a dependency.
updateSuperheroes adds superheroes to the state by creating a copy of the superheroes array and adding new entries to it.

When the superheroes state gets updated, the component re-renders with the new state, the updateSuperheroes function is created anew which causes useEffect to trigger, restarting this cycle.

What to do?

To prevent something from being created multiple times over multiple renders we often take advantage of memoization. React offers several tools to memoize our functions and values. useCallback is used for functions and useMemo is used for values such as objects or arrays.

Primitives that require a minimal computation don't need to be memoized since they are easily comparable, on the other hand, objects, functions, arrays and other complex data structures, could be created anew with every render if declared inside the component.

In our case, updateSuperheroes is a function, and should be memoized, therefore, we should leverage useCallback.



const [superheroes, setSuperheroes] = useState([]);

const updateSuperheroes = useCallback(() => {
   const newSuperhero = generateSuperhero();
   setSuperheroes([...superheroes, newSuperhero]);
}, [superheroes]);

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

But this is not enough. We can see that useCallback has a dependency on superheroes that gets changed on every run of useEffect, making this memoization redundant. For such cases, React provides us with another way to update the state without being dependent on the value.

Every state setter can get two types of the first argument.

One, a new state:



const [state, setState] = useState([])
// ...
setState([...state, 'something new']);

Or two, a function that gets the previous state as an argument and returns a new state.



const [state, setState] = useState([])
// ...
setState(previousState => [...previousState, 'something new']);

Using the latter way in our example will fix the infinite loop since there is no dependency on the state anymore. It will trigger only when the component mounts.



const [superheroes, setSuperheroes] = useState([]);

const updateSuperheroes = useCallback(() => {
   const newSuperhero = generateSuperhero();
   setSuperheroes((previousSuperheroes) => [
      ...previousSuperheroes,
      newSuperhero
   ]);
}, []);

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

In some cases, you can extract values to an outer scope (outside of the component) when a value is not dependent on any specific component code.

For example, instead of:



const emptyObject = useMemo(() => ({}, []);

Move emptyObject outside of the component code:



const emptyObject = {}

function Superheroes() {
// ...
}

This will prevent the creation of a new object instance for every render without the need to memoize it over time.

What can be so complex?

Now that we know how to handle the simple case of a state update within a useEffect, let’s delve into the more complex scenarios.

In the example above we could very easily tell which dependency in our useEffect is causing the infinite loop. Debugging more complex cases where useEffect has a large number of dependencies (and each one of them might have its own set of dependencies) is a bit harder. Finding the culprit and maintaining this code in general requires more effort.

I’ve seen colossal dependency arrays across many projects, and here are a couple of recommendations for how to deal with them.

1. Separate your gigantic `useEffect` into a few smaller ones



useEffect(() => {
   // ...
}, [
   peopleProvider,
   engineersProvider,
   doctorsProvider,
   generateUniqueId,
   initializeApp
]);

Converting this example, where a useEffect gets a large number of possibly non-related dependencies, into this:



useEffect(() => {
   // ...
}, [peopleProvider]);

useEffect(() => {
   // ...
}, [engineersProvider]);

useEffect(() => {
   // ...
}, [doctorsProvider]);

useEffect(() => {
   // ...
}, [generateUniqueId, initializeApp]);

This way we can scope our side effects into separate, smaller useEffect declarations to prevent triggering irrelevant handlers.
In other words, updated dependencies will not trigger a side effect or a state update for a non-relevant functionality.

2. Debug the dependencies that are changing on every render

If you still couldn’t find the main cause of an infinite render and you still don’t know which state gets updated and what handler is causing it, I recommend implementing or using a helper hook (such as this) that logs the changed dependencies for each render.



useEffect(() => {
   // ...
}, [
   peopleProvider,
   engineersProvider,
   doctorsProvider,
   generateUniqueId,
   initializeApp
]);

useTraceUpdate({
   peopleProvider,
   engineersProvider,
   doctorsProvider,
   generateUniqueId,
   initializeApp
});

This will log only the changed values, indicating which dependency is changing every render leading to an infinite loop.

Conclusion

Fixing and avoiding useEffect’s infinite renders can be achieved by applying the following measures:

Keep your dependency arrays short and concise. Scope the useEffect you’re creating to a specific minimal context and avoid mixing dependencies that have different intents.
Memoize complex values and functions passed to your hooks and components.
Avoid depending on a state and setting it in the same useEffect, this is a very fragile situation that can break easily. If you must have such a case, you can take advantage of the option to set the state using a function provided to setState and not be dependent on the previous value.
Find the always-changing dependency (the one that is causing the infinite render) by debugging your dependencies. Try locating the value that is causing the infinite renders and memoize it correctly.

I hope you've found this article helpful, and I look forward to see y'all at the next one!

How I improved my React development experience by leveraging visual tools

Peter Shershov — Wed, 03 Aug 2022 15:57:35 +0000

When we’re developing a UI project, being able to run and debug our components fast is the key to a good dev experience. Commonly, we do this in an isolated development environment where we render and interact with our UI.

Working in a tool that provides both rendering and editing capabilities, developers can reach even shorter cycles, and in turn, improve the development experience.

Wix Component Studio (WCS) is an editor that lets developers visually develop React components in isolation through a UI. WCS understands your code structure and edits it as a developer would, letting you focus on the features and behavior of your business logic.

Building the component

In this post, I’ll walk you through the basics of building a React gift card component for a fictional fintech company called CloudCash. I’ll show you how I did it from scratch through a combination of visual editing in WCS, through the built-in code editor, and using my own IDE.

Here’s what we’re going for:

Creating the new component

The first thing I did after opening Component Studio on my project was create a new component. I clicked on the New Component button and gave it the name “GiftCard”.

Behind the scenes, WCS created three files – gift-card.tsx in our source directory for the component, gift-card.board.tsx containing what WCS needs to render in isolation as a “board” onscreen, and gift-card.module.scss, the stylesheet for the component.

The Elements Panel on the left shows three nested elements – Window, Canvas, and our component, GiftCard. Let’s first resize the component so that it begins to look like an actual gift card by selecting the Canvas element, opening the Properties panel on the right side, and giving it a canvas size of 320px by 205px.

I’ll edit the GiftCard component now by selecting it in the Elements panel and clicking Edit Component.

This changes our editing context from the playground (board) to the actual gift card component, and any changes that I now make are made to the component’s code and affect all instances of it.

Styling the component’s root HTML element

Now that I’ve moved into the scope of the component, I’ll be applying all the styles that belong to the root HTML element. First, I’ll match the height of the component to the canvas by setting it to 100%. This is done by selecting the root node of the component, ‘div.root’ in the Elements panel, and in the Styles panel, selecting the ‘.root’ selector and setting its height.

Next, I’ll set the background color to ‘#282B2D’, the text color to white, and the border radius for the corners to 18px. Finally, I’ll set the display to flex, the alignment to center, the justification to center, and the direction to column.

Adding an element to the component

Right now, I have the layout of the gift card, but my component has only a single element. I'm going to need to add an h2 element to it to give it a proper title. While I can do this in the code, WCS allows me to do it visually. I'll click the Add button in the Elements panel to open the Add Elements panel, where I can search for the h2 element and drag it over as the first child of the root element.

Now I’ll set the text by selecting the Heading 2 text element and giving it the “CloudCash” value in the Properties panel.

Adding a class to an element

When I dragged the h2 element to the Elements panel, WCS added an h2 element to my code. It does not have any class applied to it yet. To style it, I’ll need to add a class to it, and then add a selector to target this class in the component stylesheet. I’ll do this part visually through the Styles panel.

While still selected on the h2 element, I can give it the class name “title” by clicking “Create or apply a class”.

Creating the class through WCS saves effort by suggesting the component CSS file, adding the class selector to it, and applying the class to my component file in one action.

I have a new class at this point, but it doesn’t have any styling yet. Let’s fix the margin and tweak our fonts to make our gift card look a bit better. While I can edit it visually using the Styles panel, in this case I’ll choose to add my CSS through the code editor to show how the code, the stage, and the Styles panel are always in sync. I’ll jump directly to the relevant point in the code by hovering over the selector that I created above and clicking Edit Code.

This brings us to the ‘.title’ selector in the code, where I’ll add a couple of declarations to refine our component some more. I’ll copy and paste the following code snippet to my code:

.title {
    margin: -8px 0 12px;
    font-weight: 200;
    font-style: normal;
    font-size: 36px;
}

Adding a new prop to the component

To make our component truly reusable, I’ll need to have it accept a property to allow controlling the gift card amount from the outside.

We’ve already seen how I can make changes to my component visually and through the code drawer, but WCS also syncs changes to the project code on my file system. This means that I can use my own IDE.

Let's take a look at the component code created by WCS so far by opening the “gift-card.tsx” file in VS Code.

Now let’s add a property called “amount” of the string type. I’ll then destructure it in our component props, give it a default value of “$100”, and lastly, replace the “GiftCard” text in our component with the {amount} expression.

To demonstrate how easily WCS allows you to create examples for your components, I’ll go back up our scope to our original starting board, and through there, give our component an alternative prop value of “$200”. As you might imagine, this capability is very useful for complex components with multiple properties.

And with that, I’ve completed everything I set out to do, and the component is ready for use! I tried to keep this example simple to keep this post focused and concise, but I can create any design that CSS supports.

Check it out for yourself

Interested in learning more about WCS? It’s currently in alpha stage, and we’re expanding user access as we iron out the kinks and refine the overall experience.
Visit wixcomponentstudio.com to sign up for early access and try out our demo.