DEV Community: Alex Sidorenko

A Visual Guide to useEffect - Cleanups

Alex Sidorenko — Tue, 21 Dec 2021 09:04:08 +0000

This is a second chapter of the Visual Guide to useEffect

Here is a component that logs how many seconds have passed from the first time it’s rendered.

Effects may keep running after the component unmounts

Now let’s say we have two pages in our app. Only one of those pages has our component. Here is what happens when we switch between the pages.

The log keeps running after the component unmounts. How to prevent that?

Every effect may return a function that cleans up after it

React performs the cleanup when the component unmounts

React Docs - useEffect

Effects may accumulate with every execution

Let’s change our component to log how many seconds have passed from the last time it is rendered. We will need to remove the dependency array to run the effect after every re-render.

If we keep re-rendering the component, we will keep creating new intervals. How do we only keep the last interval?

React also cleans up effects from the previous render before running the effects next time

React Docs - useEffect

When to use cleanups?

Whenever you add an effect, think about what will happen when the component unmounts. Will this effect keep running? If so, provide a cleanup function. If you do that, it will automatically cover the second use case when effects accumulate with every execution.

This effect won't keep running after the component unmounts.

Doesn't require a cleanup.

useEffect(() => {
  document.title = props.title
})

This effect will keep running after the component unmounts.

Requires a cleanup.

useEffect(() => {
  const handler = () => console.log(window.pageYOffset)
  window.addEventListener("scroll", handler);
  return () => window.removeEventListener("scroll", onScroll);
})

Looking for daily snippets of visual React content? Follow me on Twitter

A 2 Minute Visual Guide to useEffect

Alex Sidorenko — Tue, 07 Dec 2021 09:11:54 +0000

Here is what happens when you try to fetch data directly from the body of a functional component in React 👇

Why does this happen and what tools does React offer to solve this problem?

Side effects

If your React component affects anything outside of itself, it's called a side effect.

Side effects shouldn't happen during component render. Therefore they do not belong to the body of a functional component. React has a special place for them.

To learn more about side effects and why they need a special treatment, check out this brilliant section in the new React documentation - Keeping Components Pure.

Dealing with side effects

The special place for side effects is inside the useEffect hook. Hence the name.

By using this Hook, you tell React that your component needs to do something after render. React will remember the function you passed (we’ll refer to it as our “effect”), and call it later after performing the DOM updates.

React Docs - Using the Effect Hook

Let's try it with our initial component:

The useEffect does not run during the render. It runs after the render, which is what we want. But we still have the same problem. That's because, by default, useEffect will run after every component render.

Running effects conditionally

There is a way to run effects conditionally, not after every render. The useEffect hook accepts the dependency list as a second argument. React will only re-run the effect if any dependency in the list changes. Let's try it out:

When you pass an empty array as a dependency list, the effect will run only once, after the first render. It prevents the infinite loop from happening in our case. However, you might notice that our fetch function relies on the props.id .

Reacting to changes

Let's pick up where we left off and see what happens when we change the component's props.

We would expect the component to react to prop change and fetch another product, but nothing happens. That's because we have an empty dependency list.

If the side effect relies on any props or state variables, we should put them in the dependency list. After every render, React will check whether any dependency has changed, and if it did, will re-run the effect.

To be continued...

There are a couple more things to learn about useEffect. Don't miss the next 2 minute guide.

https://alexsidorenko.com/

A Visual Guide to React Rendering - Refs

Alex Sidorenko — Tue, 16 Nov 2021 11:01:48 +0000

How to disable this button after 3 clicks without re-rendering the component first 2 times?

<button disabled={count === 3}>Button</button>

Storing values with refs

When you want a component to “remember” some information, but you don’t want that information to trigger new renders, you can use a ref—it’s like a secret “pocket” for storing information in your component!

React Docs - Referencing Values with Refs

Let's try to count clicks with refs instead of state.

<button disabled={count.current === 3}>Button</button>

The ref updates, but the button is still active. Why is that?

Component renders and DOM updates

To disable the button react has to update the DOM. React updates the DOM when the component renders with a different output than before. React won’t update any DOM until one of the React components render. And since changing ref doesn’t cause the component to re-render, the button stays active.

To demonstrate this point further, let's add a parent component.

By default when you render a React component it recursively re-renders all its children. That's why when we update the Parent state, it renders both Parent and Component. And when Component renders, React executes the condition and disables a button.

<button disabled={count.current === 3}>Button</button>

But surely we can not rely on parent updates to disable a button. Let's implement this behavior directly into Component.

Update state to re-render a component

We can make the component re-render by reintroducing state again. But we still don't want the component to render on first 2 clicks. So we will keep the ref to silently count the clicks. And we will add a state variable with a sole responsibility of updating the button status. Let's update butttonStatus only when the button clicked the third time.

<button
  disabled={buttonStatus === 'disabled'}
  onClick={() => {
    count.current++
    if (count.current === 3) {
      setButtonStatus('disabled')
    }
  }}
>

The example from the article has been made to demonstrate the behavior of refs. Keep in mind that unnecessary renders are not always bad, and you don't have to eliminate every one of them. In fact, in a real-world scenario, it would probably make more sense to rely solely on the state and re-render this component 3 times for simplicity. However, you will encounter different situations in your apps. Understanding refs gives you a powerful tool for fine-tuning the behavior of your components.

For daily snippets of React content, follow me on Twitter or LinkedIn.

How Code Splitting Improves Lighthouse Score

Alex Sidorenko — Tue, 02 Nov 2021 10:45:24 +0000

What if there was one single technique that could help increase this score by a lot?

Why having a large JS bundle is bad for performance

Let's say we have a single-page application with six screens. Every screen requires a particular amount of javascript to work. But since it is a single-page application, we load all javascript in one bundle and include it in our index.html.

Now, when a user lands on Home, ideally, we only want to load 100kb of javascript required for this screen. But instead, the browser has to load and parse the entire javascript bundle.

Even if the user never accesses "Admin" or "Dashboard" pages, the code for these pages will still have to be loaded. Moreover, if we don't use pre-rendering techniques, the browser will not show the Home screen until the entire bundle is loaded. Therefore bundle loading process blocks the rendering and increases the time for the First Contentful Paint.

How code-splitting helps

What if we could load the code for each screen only when the user lands on this screen. Let's say the user goes from Home to Posts to a single Post. In this case, we don't want to load javascript for Admin, Dashboard and About at all. How do we do that?

This is where code splitting comes in handy.

Code splitting is the splitting of code into various bundles or components which can then be loaded on demand or in parallel.

MDN - Code splitting

Instead of having one large javascript bundle, we split it into smaller chunks and load them on demand.

When a user lands on Home, the browser loads 100kb home.js and immediately starts rendering the Home screen. If then, the user goes to Posts, the browser loads 200kb posts.js and renders Posts screen, etc. No more unused code, no render-blocking.

How to apply code splitting

There are different code splitting techniques available for various javascript bundlers and frameworks:

Follow me on Twitter

A Visual Guide to React Rendering - Cheat Sheet

Alex Sidorenko — Tue, 19 Oct 2021 09:05:11 +0000

When does react component re-renders? What can cause the re-render, and how to prevent unnecessary renders? Here is a quick cheat sheet you can refer to whenever you find yourself asking these questions.

This article serves as a table of content for a Visual Guide to React Rendering series. Every section of the cheat sheet links to the correspondent chapter of the guide that explores a topic in depth.

Standard rendering and memo

By default, when the state of the component changes, this component and all its children re-render. You can wrap React component with memo to prevent an entire subtree from re-rendering.

A Visual Guide To React Rendering - It Always Rerenders (Chapter 1)

Primitive vs Non-primitive props

Non-primitive values in javascript are compared by reference.

{display: "flex"} === {display: "flex"} // false

Keep that in mind when passing props to memoized components. Memoized components re-render when their props change.

A Visual Guide To React Rendering - Props (Chapter 2)

Stable reference with useMemo

You can preserve a reference to a non primitive value with useMemo. It won't change on re-renders.

A Visual Guide To React Rendering - useMemo (Chapter 3)

Stable reference with useCallback

You can preserve a reference to a function with useCallback

A Visual Guide To React Rendering - useCallback (Chapter 4)

Rendering and Context

The component right under your context provider should probably use memo

A Visual Guide To React Rendering - Context (Chapter 5)

Rendering and DOM

React component render does not mean DOM update. React is smart enough to update only those parts of DOM that need to change.

A Visual Guide To React Rendering - DOM (Chapter 6)

Originally published at alexsidorenko.com

Articles on the topic:

A (Mostly) Complete Guide to React Rendering Behavior - Mark Erikson
Fix the slow render before you fix the re-render - Kent C. Dodds
Before You memo() - Dan Abramov

How to Detect Slow Renders in React?

Alex Sidorenko — Wed, 06 Oct 2021 11:19:05 +0000

Improving React app performance often comes down to finding bottlenecks and fixing them. One well-placed memoization can make a slow app fast again. But how to find performance bottlenecks?

Profile the problem

Open Rect Developer Tools Profiler tab. Click the record button to start profiling. Interact with the part of your app that feels slow, then click the record button again to stop profiling.

Analyze the results

Find a slow commit you want to improve. You can see the commits bar in the right top corner of profiling results. For more info on commits, check out React Docs - Browsing Commits.

In our case, 1st, 2nd, and 4th commits are slow. They take more than 300ms to render. Every response to a user action that takes more than 100ms breaks the connection between the action and the result (RAIL: A User-Centric Model For Performance).

Now let's pick one of these commits and check the "Flamegraph" to see what is causing this poor performance.

The Flamegraph shows our components tree. We can see that component Home and its entire sub-tree re-renders. The SearchResults component responsible for the main UI change is pretty fast and takes only 7.4ms to render. The SlowComponent takes most of the rendering time. It is the bottleneck.

Fix the bottleneck

Let's look into the code of a SlowComponent:

const SlowComponent = () => {

  // Expensive calculation that takes 300+ms
  const n = [...Array(3000000).keys()].reduce((p,c) => p + c)

  return (
    <p>Expensive calculation - {n}</p>
  )
}

We can wrap our expensive calculation with useMemo to make sure it only runs when necessary. And since we don't rely on any of the props, we can leave the dependency array empty. This way, our expensive calculation will not be re-triggered every time SlowComponent re-renders.

const SlowComponent = () => {

  const n = useMemo(() => {
    // Expensive calculation that takes 300+ms
    return [...Array(3000000).keys()].reduce((p,c) => p + c)
  }, [])

  return (
    <p>Expensive calculation - {n}</p>
  )
}

Now let's analyze performance again.

The UI feels faster already. Let's check the commits.

The 1st, 2nd, and 4th commits are still the slowest. But they each take around 12-17ms to render, which is 14 times faster than before. Let's analyze the Flamegraph to see what happened.

The SearchResults component takes the most time to render now. But since it's only 12ms, we have nothing to worry about. And now that we put our memoization in place, the SlowComponent takes only 0.3ms to render.

Originally published at alexsidorenko.com

My React App is Slow and I Don't Know Why

Alex Sidorenko — Tue, 28 Sep 2021 09:59:20 +0000

What performance testing tools are available in React world, and how to start using them?

Inspect what components are getting re-rendered

You can use React Developer Tools to get a quick overview of what components re-render. Enable option "Highlight updates when components render".

Figure out what renders to fix

Not all renders are equal. Some are less performant than others. Don't try to fix every unnecessary render. Instead, find bottlenecks and fix them. React Developer Tools Profiler tab will help you with this.

Ben Award - How to use the React Profiler to find and fix Performance Problems

Investigate other performance problems

Often, web app performance issues are not related to React. Analytics tracking libraries, excessive CSS animations, non-optimized images, iframes, and many more factors can contribute to poor performance. You can use the Chrome DevTools Performance tab to debug these issues.

Chrome Dev Tools documentation - Analyze runtime performance.

Originally published at alexsidorenko.com

React is Declarative - What Does it Mean?

Alex Sidorenko — Tue, 21 Sep 2021 11:39:08 +0000

It's drilled into you when learning React that it is declarative. But what does declarative mean, and what is the opposite of declarative

Declarative vs Imperative UI

The opposite of declarative is imperative. These are not React-specific terms. They apply to programming in general.

StackOverflow - What is the difference between declarative and imperative paradigm in programming?

In terms of web user interfaces:

The imperative approach is when you provide step-by-step DOM mutations until you reach desired UI
The declarative approach is when you describe the final state of the desired UI

Example of declarative vs imperative UI

Let's say we need to build this user interface:

Imperative approach

Here is the imperative solution. For every interaction, we provide step-by-step DOM mutations to reach the desired state of UI. (The example is slowed down to show how each instruction affects the user interface)

Declarative approach

Here is a declarative React solution. We don't provide step-by-step instructions to reach the desired UI. Instead, we describe the final UI we want for each scene.

We may structure the component differently. It doesn't make it less declarative.

What makes it declarative is that we describe a final UI for any given state representation. It is the opposite of providing manual DOM mutations to transition between UI states, which would be considered imperative.

Originally published at alexsidorenko.com

A Visual Guide to React Rendering - It Always Re-renders

Alex Sidorenko — Wed, 21 Jul 2021 14:48:00 +0000

When does a React component re-render? Is it when its state or props change?

Take a look at the gif above 👆

The structure of the app is: App > A > B > C.

Here is a slightly simplified code:

const App = () => {
  // state
  return (
    <ComponentA />
  )
}

const ComponentA = () => <ComponentB />
const ComponentB = () => <ComponentC />

Components A, B, and C don't have any props or state. Yet, they still re-render when the App renders.

In normal rendering, React does not care whether "props changed" - it will render child components unconditionally just because the parent rendered!

Mark Erikson - A (Mostly) Complete Guide to React Rendering Behavior

To illustrate this point further, let's add a state to every component and track the behavior.

When the state of C changes, only C renders. But when the state of B changes, both B and C render. The B renders because its state updates, and C renders because its parent renders.

When the state of A changes, A renders because of the state update, B renders because A rendered, and C renders because B rendered.

Avoiding re-renders

There are several ways to avoid unnecessary re-renders in React. In this article, I will only focus on React.memo and save other methods for future posts. If you are interested in alternatives to memo check out Dan Abramov's Before you memo().

Also please keep in mind that in this post, I only explore re-renders caused by direct state update, or parent render. I don't pass any props.

If you wrap a component in memo, it won't re-render when its parent renders.

Notice that C updates when its state changes, but not when the parent renders.

Lifting memo up

Let's lift memo up and see what happens.

The state update of components A, B, and C produces the same results as before. But notice the state update on the App. Wrapping a component with memo prevents the entire subtree of this component from re-rendering in response to parent render.

That's why you can hear advice like this:

Sophie Alpert

@sophiebits

That React Component Right Under Your Context Provider Should Probably Use `React.memo`

07:22 AM - 16 Feb 2020

What about adjacent components?

The same rules apply to adjacent components. The component with memo doesn't re-render in response to parent render, and therefore, prevents its entire subtree from re-rendering.

Should I memo everything?

If memo has such a great effect on performance, does it make sense to wrap everything with it? Well, not really. But this is a topic for another day. If you are interested, read Fix the slow render before you fix the re-render by Kent C. Dodds.

To be continued...

There is more to the rendering mechanism of React. To make the article simple, I purposefully left out things like passing props, context, DOM updates, and additional techniques to avoid re-rendering. I will write a separate post on each of these topics.

Originally published at alexsidorenko.com

How to stop re-rendering lists in React?

Alex Sidorenko — Wed, 14 Jul 2021 08:14:00 +0000

You have a list of components in React. The parent holds the state and passes it to the list items. Every time you update the property of one of the components in the list, the entire list re-renders. How to prevent that?

Components always re-render

First, let's simplify our example by removing all props from the Item. We will still update the parent state but won't pass any props to list items.

There is a common misconception that a React component will not re-render unless one of its properties changes. This is not true:

React does not care whether "props changed" - it will render child components unconditionally just because the parent rendered!

Mark Erikson - A (Mostly) Complete Guide to React Rendering Behavior

If you don't want a component to re-render when its parent renders, wrap it with memo. After that, the component indeed will only re-render when its props change.

const Item = memo(() => <div>Item</div>)

Applying memo to our problem

Let's get back to our initial example and wrap Item with memo. Here is a slightly simplified code.

const Item = memo(({id, value, onChange}) => {
  return (
    <input
      onChange={e => onChange(id, e.target.value)}
      value={value} />
  )
})

It doesn't work. We still have the same problem. But why?

If the component wrapped with memo re-renders, it means that one of its properties changes. Let's figure out which one.

Memoizing properties

We know from looking at the state that value only changes for one item in the list. The id property is also stable. So it must be onChange property that changes. Let's check the Parent code to see how we pass the props.

const Parent = () => {
  const [items, setItems] = useState([
    { value: '' },
    { value: '' },
    { value: '' }
  ])
  return (
    <div>
      {items.map((item, index) => (
        <Item
          key={index}
          id={index}
          value={item.value}
          onChange={(id, value) =>
            setState(state.map((item, index) => {
              return index !== id ? item : { value: value }
          })}
          />
      )}
    </div>
  )
}

Here is our problem:

onChange={(id, value) =>
  setState(state.map((item, index) => {
    return index !== id ? item : { value: value }
})}

Anonymous functions will always get a new reference on every render. This means that onChange property will change every time Parent renders. To prevent that, we need to memoize it with useCallback. Let's do that:

const Parent = () => {
  ...

  const onChange = useCallback((id, value) => {
    setItems(items.map((item, index) => {
      return index !== id ? item : { value: value }
    }))
  }, [items])

  return (
    <div>
      {items.map((item, index) => (
        <Item
          key={index}
          id={index}
          value={item.value}
          onChange={onChange}
          />
      )}
    </div>
    )
}

It still doesn't work - every component re-renders.

This happens because we put items as a dependency for useCallback . Every time items update, useCallback returns a new reference of the function. This causes onChange prop to change, therefore updating every component in the list.

To fix this, we need to stop relying on items as a dependency. We can achieve that with a functional state update:

 const onChange = useCallback((id, value) => {
    setItems(prevItems => prevItems.map((item, index) => {
      return index !== id ? item : { value: value }
    }))
  }, []) // No dependencies

Now, the only property of the Item that changes is value. And since we only update one value at a time, it prevents other components in the list from re-rendering.

Should I do that for every list?

You don't have to optimize every unnecessary re-render in React. React render is quite performant. It only updates DOM when needed. And memo comes with a small performance cost as well. Optimize it when you have a lot of items in the list and your render function is expensive.

I would assume that the same general advice applies for React.memo as it does for shouldComponentUpdate and PureComponent: doing comparisons does have a small cost, and there's scenarios where a component would never memoize properly (especially if it makes use of props.children). So, don't just automatically wrap everything everywhere. See how your app behaves in production mode, use React's profiling builds and the DevTools profiler to see where bottlenecks are, and strategically use these tools to optimize parts of the component tree that will actually benefit from these optimizations.

Mark Erikson - When should you NOT use React memo?

Before you memo - Dan Abramov
Fix the slow render before you fix the re-render - Kent C. Dodds

Originally published at alexsidorenko.com

3 ways to cause an infinite loop in React

Alex Sidorenko — Tue, 06 Jul 2021 10:56:02 +0000

Have you spent some time trying to debug an infinite loop in React? Maybe you hung your browser a couple of times in the process. Or had one of these 👇

Uncaught Error: Too many re-renders.
React limits the number of renders
to prevent an infinite loop.

Here are 3 potential causes of the infinite loop in React.

I. Updating the state inside the render

function App() {
  const [count, setCount] = useState(0);

  setCount(1); // infinite loop

  return ...
}

If you update the state directly inside your render method or a body of a functional component, it will cause an infinite loop.

State updates → triggers re-render → state updates → triggers re-render → ...

Fix 🎉

Do you want to update a state only one time when the component mounts? Use useEffect with an empty array as a dependency.

function App() {
  const [count, setCount] = useState(0);

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


  return ...
}

II. Infinite loop in useEffect

function App() {
  const [count, setCount] = useState(0);

  useEffect(() => {
    setCount(count + 1) // infinite loop
  }, [count])

  return ...
}

If you keep updating a state inside useEffect with a property you update set as a dependency, it will cause an infinite loop.

count updates → useEffect detects updated dependency → count updates → useEffect detects updated dependency → ...

Fix 🎉

If you want to update a state based on its previous value, use a functional update. This way, you can remove state property from the dependency list and prevent an infinite loop.

function App() {
  const [count, setCount] = useState(0);

  useEffect(() => {
    setCount(previousCount => previousCount + 1)
  }, [])

  return ...
}

III. Incorrectly set event handlers

export default function App() {
  const [count, setCount] = useState(0);

  return (
    <button onClick={setCount(1)}>Submit</button> // infinite loop
  );
}

It is not the right way to set event handlers. You need to provide a function to the onClick, not the result of the function execution. By executing a function before setting a handler, you update a state inside the render, which causes an infinite loop.

State updates → triggers re-render → state updates → triggers re-render → ...

Fix 🎉

Set a function to onClick event. It is a proper way to set event handlers. This way state will only update after a click of a button and won't cause an infinite loop.

export default function App() {
  const [count, setCount] = useState(0);

  return (
    <button onClick={() => setCount(1)}>Submit</button> // infinite loop
  );
}

How to spot infinite loops

Every time you update a state, picture the sequence of events that will happen after the update. If without additional user interaction, this sequence leads you back to the same state update, you probably have an infinite loop.

Discuss on Twitter

Why is it so difficult to modify a deeply nested state in React?

Alex Sidorenko — Tue, 29 Jun 2021 10:47:42 +0000

It's not uncommon to see a code like that in React world. All this effort just to update a single to-do item inside a nested state.

const updateTodo = ({taskId, todoId, value}) => {
  setProject({
    tasks: {
      ...state.tasks,
      [taskId]: {
        ...state.tasks[taskId],
        todos: {
          ...state.tasks[taskId].todos,
          [todoId]: {
            value: value
          }
        }
      }
    }
  })
}

But how come that such a popular, widely spread tool as React makes such a hustle from something that a beginner may bump into during the first project? Is that really so that solo React can not tackle deeply nested state updates with less boilerplate? Isn't it a bit disappointing?

Immutability trade-off

React embraces the concept of immutability. The above code example updates the state immutably. It means that it doesn't modify the state directly. Instead, it creates a new copy of the state. In comparison, this how a direct mutation of the state would look like:

project.tasks[taskId].todos[todoId].value = true

But why is immutability so important if it makes the trivial task of updating a state so complicated? Here are three main reasons from React documentation:

I

Immutability makes complex features much easier to implement. Avoiding direct data mutation lets us keep previous versions of the state history intact, and reuse them later.

II

Detecting changes in mutable objects is difficult because they are modified directly. This detection requires the mutable object to be compared to previous copies of itself and the entire object tree to be traversed.

III

The main benefit of immutability is that it helps you build pure components in React. Immutable data can easily determine if changes have been made, which helps to determine when a component requires re-rendering.

More information on immutability:

Ok, I get it - immutability is important, but how do I update my nested state?

There are two main ways to simplify nested state updates in React - flattening the state and using immutable libraries.

Flattening the state

The best solution is to avoid the problem. If you have a nested state, try to flatten it. Check out three main reasons to keep your state flat by the Redux maintainer, Mark Erikson. You can try to flatten your state by hand or use a third-party library, like Normalirz.

Using immutable libraries

There are libraries out there that are designed to help with immutable updates. For example, here is how Immer can help to reduce our boilerplate.

const updateTodo = ({taskId, todoId, value}) => {
  setState(produce(baseState, draftState => {
     draftState.tasks[taskId].todos[todoId].value = value
     return draftState
  }))
}

Check out top 13 immutable libraries

Summary

The pain of updating a nested state stems from the fundamental architectural decision of the React to embrace immutability. Immutability comes with plenty of great benefits, such as predictability and performance, so the trade-off is worth it.

There are two main ways to deal with the problem of updating a deeply nested state. First is flattening your state to avoid the problem altogether. The second is using immutable libraries that help with state manipulations.

Originally published at alexsidorenko.com