[ricardobeat]

How telling is it that a basic core function like useFetch has a warning that it “depends on React’s experimental useEffectEvent”?

Almost a decade later and simple data fetching is still an unsolved “problem” in React land.

[toddmatthews]

react is a rendering engine, not a framework; there is no opinionated way to fetch data.

react-query is a delightful library that has made data fetching/cacheing a breeze for me - https://tanstack.com/query/v3/docs/react/overview

[ricardobeat]

That ceased to be true long ago. How do you use native fetch() with a functional component achieving correct/expected behaviour? It’s not possible without buying into react’s [very opinionated] hooks.

In fact, the toolbox this whole HN entry is about is a great example of how React is not just a rendering engine. It wouldn’t even be necessary otherwise. Peek at the code and what you’ll see is intense use of a DSL and built-in methods provided by React, to wrap native APIs that are otherwise usable without any wrappers.

I’m also a happy user of react-query, but it uses the same underlying hooks which are a moving target.

[parabyl]

I'm quite experienced with React itself (and have given RSC a spin more recently) - but I've been trying to understand, aside from using a top-level `await fetch` in a server component, is there a possible route to implementing this in client components themselves? Without using a useEffect to call the fetch and populate state with a DIY / ReactQuery style error/loading/component, that is.

My understand was previously that it wasn't really feasible, but seeing the RSC additions (as well as Next's own explorations into calling Server-side code from client components) I was wondering if it wasn't just avoided to go the route away from hooks since they're such a large 'caveat' already that it's only worth doubling down on them.

[flagrant_taco]

This may very well change. I won't be surprised to see react have to become more opinionated about days fetching now that they are dancing between client and server with some form of an rpc.

For performance and security I could see them pushing for all data loading to be done on the server, complete with helpers and server-only hooks for fetching and streaming data from the server.

[Vinnl]

> This may very well change. I won't be surprised to see react have to become more opinionated about days fetching

This is already happening, as I understand it they're even going as far as monkey-patching the Fetch API: https://nextjs.org/docs/app/building-your-application/data-f...

(But maybe let's leave discussion on that particular approach to different posts, we're going off-topic enough as it is.)

[Vinnl]

The problem of data fetching is basically the problem of caching, famously one of the two hardest problems in computer science.

[shmde]

Whats the other one ?

[whatsdoom]

naming things and off-by-one errors

[toddmatthews]

naming things

[hombre_fatal]

I guess you are thinking that because it has a simple name on the website, "useFetch", that it's some sort of canonical http client for React, but it's not.

The only thing it telegraphs is that the ui.dev people built an http client hook (with opinionated features like caching) that uses cutting edge features to do things that people are already doing in React without experimental features.

[ketzo]

It’s not “unsolved” - it’s just mostly left to the massive number of third-party data-fetching solutions built on top of React.

[seattle_spring]

How does this suggest, in any way, that fetching is an “unsolved problem” in “React land”?

[zwily]

I can’t seem to even find useFetch in the source….

[jackdh]

It's not ideal, but on the website if you open the sources you can search for them (You'll need to click on the hook first so it loads the demo). However they're not typed of course. On Chromium it's just control+p then useFetch and you should see it.