*/}  
    
    
          <List items={visibleTodos} />  
    
    
        </div>  
    
    
      );  
    
    
    }

**In the above example, the` filterTodos ` function always creates a
_different_ array, ** similar to how the ` {} ` object literal always creates
a new object. Normally, this wouldn’t be a problem, but it means that ` List `
props will never be the same, and your [ ` memo ` ](/reference/react/memo)
optimization won’t work. This is where ` useMemo ` comes in handy:

    
    
    export default function TodoList({ todos, tab, theme }) {  
    
    
      // Tell React to cache your calculation between re-renders...  
    
    
      const visibleTodos = useMemo(  
    
    
        () => filterTodos(todos, tab),  
    
    
        [todos, tab] // ...so as long as these dependencies don't change...  
    
    
      );  
    
    
      return (  
    
    
        <div className={theme}>  
    
    
          {/* ...List will receive the same props and can skip re-rendering */}  
    
    
          <List items={visibleTodos} />  
    
    
        </div>  
    
    
      );  
    
    
    }

**By wrapping the` visibleTodos ` calculation in ` useMemo ` , you ensure that
it has the _same_ value between the re-renders ** (until dependencies change).
You don’t _have to_ wrap a calculation in ` useMemo ` unless you do it for
some specific reason. In this example, the reason is that you pass it to a
component wrapped in [ ` memo ` , ](/reference/react/memo) and this lets it
skip re-rendering. There are a few other reasons to add ` useMemo ` which are
described further on this page.

#####  Deep Dive

####  Memoizing individual JSX nodes

Show Details

Instead of wrapping ` List ` in [ ` memo ` ](/reference/react/memo) , you
could wrap the ` <List /> ` JSX node itself in ` useMemo ` :

    
    
    export default function TodoList({ todos, tab, theme }) {  
    
    
      const visibleTodos = useMemo(() => filterTodos(todos, tab), [todos, tab]);  
    
    
      const children = useMemo(() => <List items={visibleTodos} />, [visibleTodos]);  
    
    
      return (  
    
    
        <div className={theme}>  
    
    
          {children}  
    
    
        </div>  
    
    
      );  
    
    
    }

The behavior would be the same. If the ` visibleTodos ` haven’t changed, `
List ` won’t be re-rendered.

A JSX node like ` <List items={visibleTodos} /> ` is an object like ` { type:
List, props: { items: visibleTodos } } ` . Creating this object is very cheap,
but React doesn’t know whether its contents is the same as last time or not.
This is why by default, React will re-render the ` List ` component.

However, if React sees the same exact JSX as during the previous render, it
won’t try to re-render your component. This is because JSX nodes are [
immutable. ](https://en.wikipedia.org/wiki/Immutable_object) A JSX node object
could not have changed over time, so React knows it’s safe to skip a re-
render. However, for this to work, the node has to _actually be the same
object_ , not merely look the same in code. This is what ` useMemo ` does in
this example.

Manually wrapping JSX nodes into ` useMemo ` is not convenient. For example,
you can’t do this conditionally. This is usually why you would wrap components
with [ ` memo ` ](/reference/react/memo) instead of wrapping JSX nodes.

####  The difference between skipping re-renders and always re-rendering

1  .  Skipping re-rendering with ` useMemo ` and ` memo ` 2  .  Always re-
rendering a component

####

Example  1  of  2  :

Skipping re-rendering with ` useMemo ` and ` memo `

In this example, the ` List ` component is **artificially slowed down** so
that you can see what happens when a React component you’re rendering is
genuinely slow. Try switching the tabs and toggling the theme.

Switching the tabs feels slow because it forces the slowed down ` List ` to
re-render. That’s expected because the ` tab ` has changed, and so you need to
reflect th