DEV Community: Ekaterina Anishkina

Yet another React Dos and Don'ts

Ekaterina Anishkina — Wed, 08 Nov 2023 07:57:03 +0000

It’s another one of the React Dos and Don'ts which you have found a lot on the internet. But give me a chance and keep reading. I’ve been developing React web applications for about 8 years. For the last 3 years I’ve been working on optimizing React apps to make them fast with good FPS. Let’s get started.
The React team has created really good and detailed documentation. I like it much more than the previous one. My favorite part is about the Render and Commit phases. Please read it if you haven’t. The most common mistake that I’ve seen during code reviews was triggering a redundant commit phase. It’s important to batch state updates and avoid triggering setState synchronously in effect.

Don’t

const ModalWithState = ({ isVisible }) => {
  const [isModalContentVisible, setIsModalContentVisible] = useState(isVisible);

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

  return (
    <Modal
      isModalContentVisible={isModalContentVisible}
      onShow={() => {
        setIsModalContentVisible(true);
      }}
      onClose={() => {
        setIsModalContentVisible(false);
      }}
    >
      <div>Modal content</div>
    </Modal>
  );
};

const ModalWithState = ({ isVisible }) => {
  const [isModalContentVisible, setIsModalContentVisible] = useState(isVisible);
  const [prevIsVisible, setIsPrevIsVisible] = useState(isVisible);

  if (isVisible !== prevIsVisible) {
    setIsModalContentVisible(isVisible);
    setIsPrevIsVisible(isVisible);
  }

  return (
    <Modal
      isModalContentVisible={isModalContentVisible}
      onShow={() => {
        setIsModalContentVisible(true);
      }}
      onClose={() => {
        setIsModalContentVisible(false);
      }}
    >
      <div>Modal content</div>
    </Modal>
  );
};

There are some exceptions when it’s necessary to update state synchronously. E.g. when handling different client and server content.
And keep in mind - “Always check whether you can reset all state with a key or calculate everything during rendering instead”.

The next part is a long discussion about when to use useCallback/useMemo and when not to.
There are two opposite approaches:

Use it only when you’ve identified performance bottlenecks. There is a good article about this called - When to useMemo and useCallback.
You can “put down a pillow” and use it everywhere. I have run tests and found that it has a negative impact on performance only with high numbers of useMemo/useCallback usage on the page (from ~2000 on weaker devices).

I recommend striking a happy medium.

If you never benefit from that, don’s use it:
  1.1. Don’t use useCallback when you pass event handlers as props in the base components (like button, div, etc.)
  1.2. Don’t use useMemo for primitive memoization.
  1.3. Free memoization is always the best one to use.
If you definitely benefit from that now or in the future:
  2.1. Apply useCallback if you pass event handlers in the memoized components.
  2.2. Don’t pass new functions or objects via context for every render unintentionally.
  2.3. Use useCallback/useMemo when you don’t want to trigger effects for every render.
  2.4. Use useCallback for non-base components.

1.1. Don’t use `useCallback` when you pass event handlers as props in the base components (like button, div, etc.)

In the example below <button> is a base component. If you use css-in-js please keep in mind that the styled button is also actually the base component.

Don’t

const Parent = ({ value }) => {
    const [v, setV] = useState(0);

    const onClick = useCallback(() => setV(v => v + 1), []);

    return <button onClick={onClick}>Click me</button>;
}

const Parent = ({ value }) => {
    const [v, setV] = useState(0);

    return <button onClick={() => setV(v => v + 1)} />;
}

1.2. Don’t use `useMemo` for primitive memoization.

A huge number of useMemo usage (2K - 100K, depending on device) could increase render time by 50%. I believe that ~2K useMemo is a rare case for production applications, but why do you use it if there is no sense.

Don’t

const MyComponent = ({ value }) => {
    const text = useMemo(() => `My value is ${value}`, [value]);

    return <div>{text}</div>;
}

const MyComponent = ({ value }) => {
    const text = `My value is ${value}`;

    return <div>{text}</div>;
}

1.3. Free memoization is always the best one to use.

I hope you have a good habit of moving initializations of constants outside of the render. In a very artificial example with a huge amount of re-renders there is a render degradation up to 60%.

Don’t

const MyComponent = () => {
    const list = useMemo(() => ['one', 'two', 'three', 'four'], []);

    return <ChildMemo list={list} />;
}

const LIST = ['one', 'two', 'three', 'four'];

const MyComponent = () => {
    return <ChildMemo list={LIST} />;
}

The cases below if you need it now or it could be applicable in the future.

2.1. Apply `useCallback` if you pass event handlers in the memoized components.

Don’t

const ChildMemo = memo(function Child() {
    return  <button onClick={onClick}>Click me</button>;
});

const Parent = () => {
    const [v, setV] = useState(0);

    return <ChildMemo onClick={() => setV(v => v + 1)} />;
}

const Parent = () => {
    const [v, setV] = useState(0);

    const handleOnClick = useCallback(() => setV(v => v + 1), []);

    return <ChildMemo onClick={handleOnClick} />;
}

2.2. Don’t pass new functions or objects via context for every render unintentionally.

It avoids redundant re-renders of context subscribed components. You can find details in the documentation - Optimizing re-renders when passing objects and functions. I recommend enabling the eslint rule regarding that - react/jsx-no-constructed-context-values.

Don’t

return (
    <SomeContext.Provider value={{ foo: 'bar' }}>
        ...
    </SomeContext.Provider>
)

const foo = useMemo(() => ({ foo: 'bar' }), []);
return (
    <SomeContext.Provider value={foo}>
        ...
    </SomeContext.Provider>
)

2.3. Always use `useCallback` if you don’t want to trigger effects for every render.

Also it gets rid of the disabling eslint rule // eslint-disable-next-line react-hooks/exhaustive-deps.

Don’t

const Child = ({ handleData, data }) => {
    useEffect(() => {
        myFetch().then((res) => {
            handleData(res);
        })
    // eslint-disable-next-line react-hooks/exhaustive-deps
    }, [])

    return <div>{data}</div>
};

const Parent = () => {
    const [data, setData] = useState(null);

    return <Child handleData={(data) => setData(data)} data={data} />;
}

const Child = ({ handleData, data }) => {
    useEffect(() => {
        myFetch().then((res) => {
            handleData(res);
        })
    }, [handleData])

    return <div>{data}</div>
};

const Parent = () => {
    const [data, setData] = useState(null);

    const handleData = useCallback((data) => setData(data), []);

    return <Child handleData={handleData} data={data} />;
}

2.4. Call `useCallback` for non base components.

Because in the future these components can be transformed to memoised components and such event handlers can break memoization.

Don’t

const Parent = ({ value }) => {
    const [v, setV] = useState(0);

    return <MyButton onClick={() => setV(v => v + 1)}>Click me</button>;
}

const Parent = ({ value }) => {
    const [v, setV] = useState(0);

    const handleOnClick = useCallback(() => setV(v => v + 1), []);

    return <MyButton onClick={handleOnClick} />;
}

Don’t dynamically create a new component on every render.

React will throw away the previous DOM subtree and create it from scratch instead of re-calculating the difference.
It negatively affects performance and can lead unpredictable behaviour by unmounting and mounting such components on every re-render:

All effects will be triggered.
The state will not be saved.
Memoization will be broken.

Don’t

const Parent = ({ value }) => {
    const Child = () => <div>{value}</div>;

    return <Child />;
}

const Child = ({ value }) => <div>{value}</div>;

const Parent = ({ value }) => {
    return <Child value={value} />;
}

Don’t break memoization.

When you use memo don’t pass children as props. In most cases it triggers re-render of memoized components for every parents’ re-renders. An exception is if children is a primitive data type (string, number, etc.).

Don’t

const Child = () => {
    return <div>child</div>;
};

const MemoComponent = memo(function MemoComponent({ children }) {
    // some heavy render

    return <div>{children}</div>;
});

const Parent = () => {
    return (
        <MemoComponent>
            <Child />
        </MemoComponent>
    );
};

Do1 (better than Do2)

const Child = () => {
    return <div>child</div>;
};

const MemoComponent = memo(function MemoComponent() {
    // some heavy render

    return (
        <div>
            <Child />
        </div>
    );
});

const Parent = () => {
    return <MemoComponent />;
};

Do2

const Child = () => {
    return <div>child</div>;
};

const MemoComponent = memo(function MemoComponent({ children }) {
    // some heavy render

    return <div>{children}</div>;
});

const Parent = () => {
    const memoChild = useMemo(() => <Child />, [])

    return (
        <MemoComponent>
            {memoChild}
        </MemoComponent>
    );
};

`useReducer` is often a better option.

Sometimes developers prefer to use a lot of useState instead of one useReducer. And I failed to find the valid reasons for that. Since we have automatic batching in React 18 this leads to less performance bottlenecks but it has still been a bad option. In the very artificial example with 11 useState instead of 1 useReducer there is a 45% re-render time growth.

Don’t

const MyComponent = ({ id }) => {
    const [data, setData] = useState(null);
    const [isLoading, setIsLoading] = useState(true);
    const [error, setError] = useState(false);

    useEffect(() => {
        setIsLoading(true);
        myFetch(id).then((data) => {
            setData(data);
            setError(null);
        }).catch((e) => {
            setError(e);
        }).finally(() => {
            setIsLoading(false);
        })

    }, [id])

    if (isLoading) {
        return 'Loading';
    }

    if (error) {
        return 'Error';
    }

    return <div>{data}</div>;
}

const reducer = (state, action) => {
    switch (action.type) {
        case 'set data': {
            return {
                ...state,
                isLoading: false,
                error: null,
                data: action.payload,
            }
        }
        case 'set isLoading': {
            return {
                ...state,
                isLoading: action.payload,
            }
        }
        case 'set error': {
            return {
                ...state,
                error: action.payload,
            }
        }
        default: {
            throw Error('Unknown action: ' + action.type);
        }
    }
};

const MyComponent = ({ id }) => {
    const [{ data, isLoading, error }, dispatch] = useReducer(reducer, {
        data: null,
        isLoading: true,
        error: null,
    });

    useEffect(() => {
        dispatch({ type: 'set isLoading', payload: true });
        myFetch(id).then((data) => {
            dispatch({ type: 'set data', payload: data });
        }).catch((e) => {
            dispatch({ type: 'set error', payload: e });
        })
    }, [id])

    if (isLoading) {
        return 'Loading';
    }

    if (error) {
        return 'Error';
    }

    return <div>{data}</div>;
}

`useState` lazy initialization helps you avoid expensive calculations on every render.

There is documentation.

Don’t

const MyComponent = (props) => {
    const [value, setValue] = useState(calculateSomethingExpensive(props));

    return <div>{value}</button>;
}

const MyComponent = (props) => {
    const [value, setValue] = useState(() => calculateSomethingExpensive(props));

    return <div>{value}</button>;
}

Keep you render pure.

Otherwise it could lead to different bugs such as unpredictable ref values.

Don’t

const MyComponent = (props) => {
    const ref = useRef(props);
    ref.current = props;

    return <div>text</div>;
}

const MyComponent = (props) => {
    const ref = useRef(props);

    useEffect(() => {
        ref.current = props;
    })

    return <div>text</div>;
}

I hope you’ve found something useful for yourself. Happy coding!

Fetching API Data with React Hooks, HOC or Render Prop

Ekaterina Anishkina — Sun, 23 Jun 2019 20:24:44 +0000

Let’s look at the implementation of data fetching using a new friend React Hooks along with good old friends: Render Prop and HOC (Higher Order Component). And find out if it’s true — ‘Old friends and old wine are the best’.

As life goes on changes, React changes for the better. In January 2019 React Hooks were added in React 16.8.0. Since then we can use local state and run side effects in functional components. Hooray! Nobody believed that it’s possible but everybody was dreaming about it. Before reading this article please make sure that you have read documentation about React Hooks.

React Hooks give an opportunity to stop using HOC and Render Prop in most of the cases. Since we have a lot of complaints about them:

HOC + Render Prop:

“Wrapper hell” makes it complicated to read code and debug.

HOC:

Problems with type annotation (flow, TypeScript).
Sometimes it’s hard to determine an owner of component props.
Props “naming collision”. You can override prop values with the same key.
HOC composition is not always evident. E.g. you need “Authorisation HOC” wrapped component after “Profile Fetcher HOC”. It means “Authorisation HOC” should be executed first.

Render Prop:

Render Prop usually doesn’t render any HTML elements, is used alongside JSX.
Useless “git diff” due to line indenting for the whole JSX inside Render Prop. It looks you changed a lot, but actually just added only one Render Prop.

Let’s take a deeper dive and look at the example that demonstrates what is better — React Hooks or Render Prop. We will use Render Prop, its implementation is similar to HOC and less verbose. We will write a utility that fetches data from API. I’m pretty sure you’ve already coded this dozen times, so let’s see if we can write it better and more elegant.

We’ll use the popular library “axios”. With the simplest scenario we should handle the following statuses and actions:

fetching process (isFetching)
success response (responseData)
failed response (error)
cancel request and send the new one if the url is changed
cancel request for an unmounted component

1. Simple scenario

Let’s write initial state and a reducer function, which modifies state depending on fetched result: success or error.

Note: The term “Reducer” came from functional programming. A lot of JS developers learned it from Redux. It is a function that accepts the current state and an action and returns the new state.

We’ll use this function in both approaches.

We fetch data by calling axios.get() with url. Then we handle success and error statuses by dispatching an action to update the state. Don’t forget to cancel the request if the url has changed or the component has been unmounted. It’s simple, but we could write it differently. Let’s highlight the pros of these two approaches:

Hooks:

Less code.
Side-effect (data fetching) is easier to read, since it’s all in one place and not spread over the lifecycle methods.
Request cancellation goes after request immediately.
Simple code to trigger a side effect in response to prop changes.

Render Prop:

It’s obvious in which lifecycle phase our code is executed.

It’s a fact that Hooks allow to write less code. So the effectiveness of you as a developer is growing. But you have to understand a new paradigm.

Everything is clear if you have lifecycle methods. We send initial request when a component is mounted (componentDidMount). Then refetch data and cancel the previous request if the props have changed (componentDidUpdate). And don’t forget to cancel the request if the component is unmounted (componentWillUnmount).

But now we perform all these side effects in the render. React team has taught us that it’s wrong. Hmm, it’s not in the render actually, but inside the useEffect hook, which will execute something asynchronously after each commit phase and DOM paint.

We don’t need to fetch data after every render, only after the initial one and whenever the url changes. That’s why we pass the url as the second argument in useEffect.

A new paradigm. To understand Hooks we need to learn new things. The most important one is the difference between the two phases: render and commit. In the render phase React figures out what changes should be applied to the DOM by comparing the results of the previous and the current render. In the commit phase React applies these changes to the DOM. During the commit phase componentDidMount and componentDidUpdate are called synchronously before the browser updates the screen. You might block the browser if you perform some large synchronous operations. Unlike these methods, the function passed to useEffect will be called asynchronously and will not block the browser from painting.

Another nice feature — useEffect will clean up after the previous effect and after a component is unmounted. Thanks to Rx that inspires the React team to take this approach.

Our utility usage is more convenient with Hooks.

Render Prop cons:

It is not clear whether any markup is added or it’s just logic.
If you want to use Render Prop state inside lifecycle methods you will have to create an extra class component.

Let’s add a new feature — trigger a new request by a user action. We will make a button that if clicked fetches a new avatar of your favourite developer.

2. Update data by user action

We will add a button that sends a request with a new username. The simplest solution is to store username in the component state and use it instead of passing it from props directly. . But in that case we will have to “copy-paste” this code for every component which need the same logic. To avoid “copy-pasting” let’s carry out this functionality into our utility.

We’ll use it in the following way:

Let’s code. Below are only the changes compared with the previous version.

If you look closely at the code you can notice:

url is stored inside our utility;
defaultUrl lets us identify that the url update is caused by the props. We need to keep track of the current props.url, otherwise a new request will not be sent;
a new function ‘update’ has appeared. We return it to the component to send a new request by clicking the button.

With Render Prop we need getDerivedStateFromProps to update the local state in case of props.url changes. But with Hooks you can change the state in the render, there are no new abstractions. Finally we can modify the component state in the render, hooray!!!

Hooks require the only complication — the “update” function must be memoized so it’s not re-created on every render. In Render Prop “update” is simply a class method.

3. API polling

Now we are going to add another popular feature. Sometimes you constantly have to poll your API. For example, your favourite developer might have changed the avatar so you should be the first one to know. We need a polling parameter — interval.

Usage:

Implementation:

We created a new action type “poll” that increments “state.requestId” by one. If data is not being fetched we dispatch “poll” with setTimeout once the interval expires. Then we should send a new request when “state.requestId” changes.

With Hooks:

perform setTimeout in a new useEffect,
pass the new argument “requestId” in the old useEffect with data fetching.

With Render Prop:

perform setTimeout in componentDidUpdate,
compare previous to new “requestId” and “isFetching”,
clear “timeoutId” in two places,
add “timeoutId” class property.

With Hooks we can express the same things cleaner and shorter than we used to.

4. What’s next?

We can continue to expand the functionality of the utility: different configurations of query parameters, data caching, response and error handlers, data refresh with the same parameters — these are regular operations in any large web application. In our project we extracted all these features in a separate component. Yes, a component! It was Render Prop. Since Hooks have appeared we converted the component into a hook (useAxiosRequest) and we even found some bugs that we didn’t notice before! You can try it here.

Contributions are always welcome!
https://github.com/Turanchoks/use-axios-request

DEV Community: Ekaterina Anishkina

Yet another React Dos and Don'ts

1.1. Don’t use useCallback when you pass event handlers as props in the base components (like button, div, etc.)

1.2. Don’t use useMemo for primitive memoization.

1.3. Free memoization is always the best one to use.

2.1. Apply useCallback if you pass event handlers in the memoized components.

2.2. Don’t pass new functions or objects via context for every render unintentionally.

2.3. Always use useCallback if you don’t want to trigger effects for every render.

2.4. Call useCallback for non base components.

Don’t dynamically create a new component on every render.

Don’t break memoization.

useReducer is often a better option.

useState lazy initialization helps you avoid expensive calculations on every render.

Keep you render pure.

Fetching API Data with React Hooks, HOC or Render Prop

1. Simple scenario

2. Update data by user action

3. API polling

4. What’s next?

1.1. Don’t use `useCallback` when you pass event handlers as props in the base components (like button, div, etc.)

1.2. Don’t use `useMemo` for primitive memoization.

2.1. Apply `useCallback` if you pass event handlers in the memoized components.

2.3. Always use `useCallback` if you don’t want to trigger effects for every render.

2.4. Call `useCallback` for non base components.

`useReducer` is often a better option.

`useState` lazy initialization helps you avoid expensive calculations on every render.