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.
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.
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.
react-query is a delightful library that has made data fetching/cacheing a breeze for me - https://tanstack.com/query/v3/docs/react/overview