5 ms·
Okay, but my point is that somewhere along the line there always is a useEffect() that reacts to something. Maybe it's in your own component, maybe it's in a th
by kennu 3y ago
Okay, but my point is that somewhere along the line there always is a useEffect() that reacts to something. Maybe it's in your own component, maybe it's in a third party component.
- scotty79 3y agoI don't agree with your point. You can use state setter from outside of react and inside react rely only on state and props and not use useEffect() at all. You don't need useEffect() to react to anything. React itself reacts to state and props change. You'll do yourself a favor if you ban yourself from using state setters inside useEffect(). Try it.
- kennu 3y agoI think that would only make my apps much more complicated, and also more difficult to understand and to develop, since they would not rely on standard React API but some kind of outside integration. I don't really see the value.
- scotty79 3y ago> I don't really see the value. One benefit is performance. useEffect() causes cascading updates when it alters state. The other is that it's way harder for your code to turn into spaghetti if you don't sidestep the whole concept of React where raw events trigger global state updates which causes react to do automatic re-render of UI which provides user with means of generating events. React should have one large loop, not multitude of small ad-hoc ones built on the side with useEffect().