What you should have gotten from this list of every possible use (and misuse) of useEffect is that it's for interaction with external things. And if you are doing a lot of interafacing with external stuff you should use a dedicated service for it, not pollute your code with ad-hoc bits of interaction, each wrapped in their own bespoke useEffect().
And the linked section talks about specifying dependencies of the code block inside useEffect()
You don't define dependencies WITH useEffect. You define dependencies OF useEffect. And you don't have much choice in the matter. Any local variable (also parameter) of render function needs to be a dependency of useEffect code. As this section states.
You can overuse useEffect() for sure. But I don't know how else you'd react e.g. to the page query string parameters or component properties changing, when the rendered content depends on them.
The whole point is not to use it directly in your components. It is implementation detail of that particular router. You might use router that interfaces with Redux not React directly.
Or you could write your router in the form of a service that lives directly in the history api event handlers and communicates directly though react state setters of some top-level component. Not a single useEffect needed.
Besides, router doesn't usually send you anything. It just sets props on your components according to url.
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.
I 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.
I 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.
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().
You do you. But notice how many people here complain about performance and piling up mess in their React projects. Avoiding useEffect is a way to avoid those issues.
What you should have gotten from this list of every possible use (and misuse) of useEffect is that it's for interaction with external things. And if you are doing a lot of interafacing with external stuff you should use a dedicated service for it, not pollute your code with ad-hoc bits of interaction, each wrapped in their own bespoke useEffect().
And the linked section talks about specifying dependencies of the code block inside useEffect()
You don't define dependencies WITH useEffect. You define dependencies OF useEffect. And you don't have much choice in the matter. Any local variable (also parameter) of render function needs to be a dependency of useEffect code. As this section states.
Here are some common misuses: https://react.dev/learn/you-might-not-need-an-effect