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. - ThreadSky

jherr.dev • 89 days ago

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.

Comments

raf.dev•89 days ago

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.

snew92.bsky.social•89 days ago

I think it's more generally applicable to say Suspense loading patterns offers more composition options than this direct loading pattern.

coolsoftware.dev•89 days ago

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

raf.dev•89 days ago

Hmm, not sure about that. I think we get told that "this is the new way of doing things" and as developers we adopt these new patterns blindly without paying attention to the user experience. I do think this pattern is bad, based on experience, and it's ok for devs to voice disagreement with norms.

jherr.dev•89 days ago

Ok, cool. So if the pattern is bad then 1) why, and 2) what would be a better pattern?

raf.dev•89 days ago

I'm glad you asked! IMO React components are best for presentation, and business logic fetching, data processing should be put somewhere else. It's best to put these things in a place that isn't automatically reactive, like a Redux environment (thunks, ect)

raf.dev•89 days ago

This allows you to prefetch and load data without having to show the user a loading state, because this logic isn't deeply tied to rendering (you can prefetch data to redux without displaying components that depend on that data)

acemarke.dev•89 days ago

I think at that point we've gone back to the "data fetching logic is full of edge cases and you shouldn't write that code yourself, especially when there's libs that do the hard work correctly" case:

https://tkdodo.eu/blog/why-you-want-react-query

snew92.bsky.social•89 days ago

Agreed

alexz90.bsky.social•89 days ago

yes, In production everyone use RQ (or equivalent of RQ),
In demo(prototype) use useEffect to fetch data is more than fine.

coolsoftware.dev•89 days ago

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.

en-js.bsky.social•89 days ago

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.

en-js.bsky.social•89 days ago

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.

saiba.yadon.dev•89 days ago

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.

hdragomir.com•89 days ago

There's a whole cottage industry of denouncing async effects and making sure only the latest one truly resolves. Flashback to any typeahead

coolsoftware.dev•89 days ago

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.

en-js.bsky.social•89 days ago

Yup! This is why we’re encouraging people to install eslint-plugin-react-compiler - because it encodes these rules.

Comments

Posting Rules

Reply