Yes, you definitely should use multiple useEffects in your React components. Provided that you need to do so.

Why should you use multiple useEffects?

The biggest reason for having multiple useEffect statements is for the separation of concerns.

One example would be if you have a component that subscribes and fetches data from two sources. You could create two useEffect calls, one for each source.

From the above example, subscribing to a feed would likely happen when your component mounts. The user’s actions might trigger the data fetching. The fact that fetching data and subscribing to a feed would happen at different times makes this a good candidate for splitting the useEffect statement.

Refactoring into multiple useEffects

When designing your components, it is easy to fall into the trap of optimising too early. With useEffect this will manifest as creating multiple useEffects when you initially build the component.

I try to reverse this. Get one working useEffect so that your component works and then start looking at the logic of the useEffect and then split it.

Often times I will find that rather than end up with multiple useEffects, I might end up with one, and some other code that doesn’t need to be put into a useEffect call. Your mileage may vary, that is just how you typically go about building components.

Side Effects

Reading the React documentation you will notice that useEffect calls should be used for side effects to your application. This is a little tricky to understand when first using useEffect.

First, a side effect happens outside the scope of React. For example, accessing a Web API is a common side effect. Fetching data has nothing to do with a UI library.

Another side effect is subscribing to data feeds (similar to above but requires holding a connection to some feed). When subscribing you need to make sure you have code to clean up that connection when your component is out of scope.

Each side effect should probably have its own useEffect. This makes sense if you consider each side effect to be working on something entirely different.

If you find you have common code between your useEffects you could easily refactor that out to some kind of helper function.

Conclusion

useEffect calls are the bane of many developers existence. Whether it is not understanding the technical side to how they work or misunderstanding when and how they should be used. They are difficult in some regards and should be treated with care.

If you feel you can accomplish your task without a useEffect then you probably don’t need one. Just focus on side effects outside of the scope of React to guide you as you need them.

Don’t forget to check out my React page here, which contains links to common concepts and examples in React.

Also, you can follow me on Twitter/X here! And now, mastodon: @bernieslearnings@mastodon.social