I haven’t had a need for suspense, I use react query without suspense just using the data, error, isLoading etc state directly. And I don’t see Suspens as a simpler pattern necessarily. What does it get you that other patterns don’t? I’m curious to know your use cases!

  • cornflour
    link
    fedilink
    arrow-up
    3
    ·
    1 year ago

    I use it a lot when I use RSC! For traditional client-side fetching, I tried it with tanstack query but couldn’t get it to work properly (could be me setting it up wrong or because tanstack query’s suspense support is still experimental, idk), so I just fall back to doing it traditionally with isLoading and stuff 😅

      • cornflour
        link
        fedilink
        arrow-up
        1
        ·
        1 year ago

        I have been enjoying it! I think the RSC data fetching pattern is really nice, and it simplifies the logic of the app. It’s also really nice to have the same pattern for non blocking fetching (use suspense to show loading states), blocking fetching with ssr (no suspense), ssg (cache the fetch indefinitely/fetch on build), or isr (cache with revalidation time), and to be able to granually config the behaviors on the individual fetch level.

        There still some rough parts, most notably imo is the caching/revalidating side of things. Maybe I didn’t do it right, but I was struggling hard ro invalidate caches to show updated data after mutation 🥲 I currently just set all the fetches to no cache right now, and for now it is fine (i dont have so much traffic on that project that it causes an issue, just me and some of my friends testing things rn). Imo caching should be an opt in thing for optimization rather than a default, but I think thats more of the Next’s specific implementation rather than rsc in general.