useEffect is absolutely core to doing to react development with hooks. Saying "you might not need an effect" is like saying "you might not need the + operator", like yeah, sure, if you're not trying to add two numbers or concatenate a string or whatever you won't need that operator, but in like 99.999% of all applications you will need it.
I think my gripe here is the casual use of “you might not need…”. It’s inspired by the “you might not need redux” article by Dan Abramov, but the difference here is that while you might not need Redux, you most likely will need useEffect. They’re just not same in that regard.
Maybe I’m just being pedantic here, but I think how you use words matters, and in this instance a better title would be “avoid unnecessary useEffect calls” or something like that. “You might not need an effect” is just poor (sloppy?) wording, because it’s usually objectively wrong.
The reason it matters in this instance is that with the current title I’m going into the article thinking I’ll learn some new way to do effects which is better than useEffect. But the article offers no alternative to useEffect. You will need useEffect.
In both cases (this page, and the one you mention) I think you’re inferring the wrong context — which is reasonable because it’s a legitimate inference.
I think the context is “for this use case”. Neither are saying never use Redux or useEffect, but are more about the common problem of people reaching for solutions that aren’t a good fit for their problem.
I think I disagree, or at least we might disagree on what operations are common in React.
When I have seen useEffect used, it's most often uneccesary. People are using it to create dependent state (ie. when x changes, then recalculate y) or to handle the result of an event.
It's really only needed in components that handle fetch responses, which IME is much fewer than 99.9%.
Not 99.9% of components, but 99.9% of applications. Of course I haven’t actually done the numbers, but if your application fetches data or listens to browser events you will need useEffect. I’d estimate 99.9% of web apps using React do at least one of those things.
There is only one case where you should be fetching inside of useEffect, and that is with an empty dependency array to get data on first render. Pretty simple and easy to wrap your head around.
Everything else is triggered by event handlers. I work on a 70Loc react app and useEffect is used maybe once outside of this context. You really don't need it.
And I don't know what you mean by "listening to browser events" with useEffect. You really just need to use onClick and onChange.
You also don't need it to set state, you need calculated constant assignments.
