Post

Yeah, folks are getting from something that state setting in a useEffect is bad, period. So I end up getting even when it's something like this. I certainly agree sync setting is bad, but data loading like this is fine, IMHO. RQ is certainly nicer, but not required.

Technical communication is hard because technically that set state is not “in” the effect. The effect just calls the promise. But you can’t blame a lot of people for thinking this *is* inside the effect since the code is between the brackets haha.

0 reposts7 likes

No idea where this is coming from. Setting state unconditionally during the synchronous portion of useEffect is bad, for the same reason that setting state unconditionally during render is bad (infinite render loop). Setting state asynchronously eg due to timer/subscription is fine.

An async effect is generally a really bad idea though. Assuming it had actual deps, as it would for a real use-case, you’d easily end up w race conditions. Earlier promises can resolve later. You’re really better off using a library like react-query, Relay, etc.

While I agree about the async effect being a bad idea, I think you can simply use an AbortController and trigger that in the clean up function of the effect. The neat thing is you can use that controller / signal for more than just fetch.

Yes, I absolutely agree. What I’m saying is that many developers struggle to understand the difference. It’s a reasonable mistake to make. It “looks” like the code is “inside” the effect. The lines literally are. We should do better helping people understand the fundamentals.