Post

If you don’t want to use tanstack query, I like to bundle this into a useAsyncMemo hook, so that the code isn’t repeated everywhere. But replacing it with tanstack query will give you caching / reuse, retries, loading statuses, timeouts, etc, which is very handy.

I feel like people mainly have a problem with people updating state from an effect ran that was triggered by another state change. This is basically just an onMount.

I'm using TanStack Query. It can be handy if you have several pages with operations like this. Also it has an internal cache which is cool in the context of an SPA. tanstack.com/query/latest...

You would have to track if component is mounted. In React 19 it could likely be done differently. Would be great if React Compiler would allow async client components…

This is a promise though, there is nothing wrong with setting state in a promise or event listener. I am against setting state directly inside of a useEffect.

Funny enough you helped inspire this. You made a video years ago about Recoil + Module Federation. That was the starting point for my research to find composable state management (+ data fetching)

Depending on the scenario, it can either trigger infinite render loops: react.dev/reference/re... Or just a handful of unnecessary renders/renders with stale state: react.dev/learn/you-mi...

For folks proposing react-query, it should not be a valid answer to this post since internally react-query does exactly what this code does. If react-query is allowed then there's nothing wrong with this code snippet.

That’s fine for a simple single request or simple PoCs, you don’t need to over complicate things. However in a real world projects, I like TanStack Query tanstack.com/query/latest or SWR swr.vercel.app as a lightweight alternative.

Not a React answer but the principle is the same: I like to think about data fetching as a mapping of a reactive state => reactive response. Newly introduced Angular's resource, SolidJS resource (minimal APIs) and TanStack Query (a real lib) lets one think in the "mapping" mental model.

I'm not concerned with your recent sample nor this exact code; I'm concerned with what's added after. How to avoid waterfalls after 6 months of me not looking at it. How to ensure devs have data loading options top of mind for great UX depending on now their screen's features grow.

yeah, its also what the lint rules that check for this assume.

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.

Agreed

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

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.

I would use vue 🤔

But that's tricky, ricky.

What's the alternative in the stable version of react?

Cool, very curious how to implement revalidation after mutation. Is it documented? I have not found anything about that (but maybe I’m blind 😅)

I didn't know about the clearing promise cache option. Good to know it! It definitely drops most of the needs to setState in an asynchronous manner just because of a fetch call

Yeah, it’s unfortunate but right now I think it’s probably better to swing too far to “never” than to set it directly in the effect

tanstack.com/query/latest

Main reason why I like the approach of using loaders in remix/ react router. Both on the server or client depending the need. It saved me to keeping this useeffect boilerplates

useSwr

I think the new info is to never set it *directly* in a useEffect, which you aren’t ;)

I think it was more like don't use it directly inside the effect. Like if something changes just change some state.

I think that is more paranoia from seeing bad code inside useEffect that tanks performance like 2 useEffects updating states that are in each other's dependency array or using useEffect to set a new state that should be a simple derived variable with maybe a useMemo.

I would probably move the data call to its own custom hook, and do something like `useComponentData()` when setting the initial state. But I also probably wouldn't reject a PR that included the above, either.

@tanstack.com query would do

Async state manager? Nah I would rather create my own unmaintainable custom hook for data fetching that bugs out during race conditions and cannot do any caching /s

No no this stan-stack stuff is something different