Post

Mark Erikson
@acemarke.dev

I _assume_ people mean doing it synchronously in the effect, but I could be missing something

0 reposts19 likes

Jack Herrington
@jherr.dev

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.

Rafael Mendiola
@raf.dev

But honestly, I think this is a bad pattern anyway. Loading data in a React component that will render it is bad for the end user because you have to show them a loading state. It's more buttery smooth to find clever moments to prefetch and only use React once you have the data you need.

Tyler Williams
@coolsoftware.dev

I think calling this a bad pattern (the promise based one, not the lint rule) maybe goes too far. There are some times where this actually makes the most sense, and we don’t do anyone any favors by calling it “bad”. We need to help developers build nuanced judgment, IMO

Tyler Williams
@coolsoftware.dev

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.

Joe Savona
@en-js.bsky.social

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.