DEV Community

Discussion on: useEffect firing twice in React 18

 
fullstackchris profile image
Chris Frewin

Well, I made an example to finally prove what I mean. You can clearly see by both methods (either useEffect or useMemo) that the component is render twice. So its two ways of doing the exact same thing, exact same 'efficiency', the benefit with useEffect is that you get your statevariable you can use later:

codesandbox.io/s/dreamy-wood-nrvfz...

Thread Thread
 
brense profile image
Rense Bakker

Yea... Because you put the console.log inside the useEffect hook for your useEffect example :B I updated your code example for you, so it's a fair comparison:
codesandbox.io/s/distracted-goldst...

Image description

In the image you can clearly see React 18 mounting the components and doing everything twice and then you can see the 2nd render caused by the useEffect hook updating state.

Really... this rule is not a joke: useEffect is only for side effects and should not be used for derived state, thats what useMemo is for, they didnt add this hook because they were bored. If you refuse to use the useMemo hook, you should STILL not use the useEffect hook for derived state. Just use a plain old javascript variable, it has better performance than triggering a 2nd rerender.

const [someStuff, setSomeStuff] = useState([])
const derivedStuff = someStuff.filter(stuff => stuff.isBetterForPerformance)
Enter fullscreen mode Exit fullscreen mode
Thread Thread
 
fullstackchris profile image
Chris Frewin

Ok, I admit that example was stupid since I would anyway probably do that as you mentioned just with JavaScript. Therefore, I still can't see a case you would want to do useMemo anywhere. See the newest example: the "JavaScript" only, as you said, is the most efficient, better than using either useMemo or useEffect:

codesandbox.io/s/festive-chatelet-...

I think the problem is from the beginning that the original useMemo example presented would probably only make sense if the 'derived state' of question actually has dependencies on other state variables, then maybe useMemo affords you some advantage, but the way I see it, when each dependency required for this derived state changes you're going to get a rerender, regardless of if you use useMemo or useEffect. This is why stupid arguments like this are such a waste of time and composition is one of the most important skills of writing good React components.

Thread Thread
 
brense profile image
Rense Bakker

No... there's a real functional difference. Updating state in a useEffect hook triggers another rerender on top of the rerender you were already getting from the state update that caused the dependencies of your useEffect hook to change. It's very important to understand this if you're going to be using React hooks, because otherwise you will run into performance issues and unexpected app behavior down the line. useMemo does not trigger a rerender, regardless of how many dependencies you pass into it.

You can opt for putting the logic to calculate your derived state directly into the render function of your component, however, that too can become a problem, for example if you try to render a lot of components at the same time and all of them have a bunch of junk happening inside their render functions, your app will become slow, to a point where it becomes unusable.

It's not an argument, it's a fact that useMemo works this way. It memoizes expensive calculations, so they dont have to happen on each render if the dependencies did not change.