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.
Almost a decade later and simple data fetching is still an unsolved “problem” in React land.
react-query is a delightful library that has made data fetching/cacheing a breeze for me - https://tanstack.com/query/v3/docs/react/overview
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.
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.)
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.
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.
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.