Client-side fetching patterns
Unanswered
Japanese pilchard posted this in #help-forum
Japanese pilchardOP
I've been using the Next 13
I'm looking for advice on what patterns folks are using for performing requests directly from the browser, in a client component, without having the server involved. Particularly, I'm focused on interacting with 3rd-party APIs directly from the client.
Is the solution SWR/TanStack Query for
app directory for a while now, and am loving how easy it makes streaming SSR, and how straightforward communication between client components and server actions are, but still encounter times when I need to be able to fetch data in client components.I'm looking for advice on what patterns folks are using for performing requests directly from the browser, in a client component, without having the server involved. Particularly, I'm focused on interacting with 3rd-party APIs directly from the client.
Is the solution SWR/TanStack Query for
GET requests and regular old fetch for mutations? Does anyone have a pattern that allows using vanilla async/await in a sane way on the client without Next exploding? I would love to not see any more of this kind of thing:Warning: A component was suspended by an uncached promise. Creating promises inside a Client Component or hook is not yet supported, except via a Suspense-compatible library or framework.10 Replies
Japanese pilchardOP
To give some context regarding what I've explored so far, here's a few of my observations, in no particular order:
-
- Although
-
[1]: https://github.com/acdlite/rfcs/blob/first-class-promises/text/0000-first-class-support-for-promises.md#why-cant-client-components-be-async-functions
[2]: https://nextjs.org/docs/app/building-your-application/data-fetching/fetching-caching-and-revalidating#fetching-data-on-the-client-with-third-party-libraries
-
async client components are not—and may never be—supported. This would be great, but the reasons why it's complicated are clear [1].- Although
use is already available in Next, it has issues with promises created on the client, with the preferred method being to pass those promises as a prop, streaming data from the server. This doesn't work if the requests need to be made from the client.-
use with promises created on the client also has the tendency to make the component rerender multiple times, which is (a) at least not ideal and (b) breaks stuff sometimes [2].[1]: https://github.com/acdlite/rfcs/blob/first-class-promises/text/0000-first-class-support-for-promises.md#why-cant-client-components-be-async-functions
[2]: https://nextjs.org/docs/app/building-your-application/data-fetching/fetching-caching-and-revalidating#fetching-data-on-the-client-with-third-party-libraries
@Japanese pilchard I've been using the Next 13 `app` directory for a while now, and am loving how easy it makes streaming SSR, and how straightforward communication between client components and server actions are, **but still encounter times when I need to be able to fetch data *in client components***.
I'm looking for advice on what patterns folks are using for performing requests **directly from the browser, in a client component**, without having the server involved. Particularly, I'm focused on interacting with 3rd-party APIs directly from the client.
Is the solution SWR/TanStack Query for `GET` requests and regular old `fetch` for mutations? Does anyone have a pattern that allows using vanilla `async`/`await` in a sane way on the client without Next exploding? I would love to not see any more of this kind of thing:
Warning: A component was suspended by an uncached promise. Creating promises inside a Client Component or hook is not yet supported, except via a Suspense-compatible library or framework.
for client side fetching, swr/tanstack query is still the way to go. it's been working for ages and it will continue to work forever.
Japanese pilchardOP
@joulev Fair enough; my major concern was that it requires wrapping up everything in order to use existing 3rd-party API clients. One question, though: is SWR still making requests directly from the browser nowadays, or is it also somehow streaming these from a server action?
@Japanese pilchard <@484037068239142956> Fair enough; my major concern was that it requires wrapping up everything in order to use existing 3rd-party API clients. One question, though: is SWR still making requests directly from the browser nowadays, or is it also somehow streaming these from a server action?
making requests directly from the browser. server actions should not be used for data fetching.
Japanese pilchardOP
Agreed, and glad to hear it.
My compromise for the 3rd-party stuff would be to generate SWR hooks from an OpenAPI spec, which seems totally possible, but there seem to be...a lot...of options. @joulev would you happen to know one that stands above the rest?
@Japanese pilchard My compromise for the 3rd-party stuff would be to generate SWR hooks from an OpenAPI spec, which seems totally possible, but there seem to be...a lot...of options. <@484037068239142956> would you happen to know one that stands above the rest?
hmmm no... i don't do api routes and client side fetching that much nowadays. but as long as you have an api endpoint you can send requests to, you can do swr.
Japanese pilchardOP
@joulev No worries, I appreciate the advice nonetheless!
I'm going to go down the SWR/OpenAPI rabbit hole for a bit now and see what shakes out, but if anyone else has a nice pattern for vanilla
async/await in client components, I'd still be happy to hear it!well, it's pretty clear that async client components will not be supported, so best you can do without swr/rq is to wait for
use(fetch()) to work well. i would honestly just ignore all of that, client components are regular react components so i'd just make use of my knowledges about regular react components