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!

  • Max-P@lemmy.max-p.me
    link
    fedilink
    arrow-up
    8
    ·
    1 year ago

    IIRC it does more than just show a loading screen: it also suspends rendering of that entire part of the app until it’s ready. So if you’re loading many (nested) things, it delays the rendering of the whole page instead of causing multiple renders in a row that can end up feeling rather laggy to the user, especially on slower devices, and particularly when you have a page with a ton of dynamic content.

    I think it can also deal with the loading of the components themselves, if the whole page and all its subcomponents aren’t already available/bundled.

    But like any React components, there’s nothing preventing you from just making your own similar one for your specific use case. They’re not magic, they use the same APIs as you do.

    I’ve never used Suspense personally but I also haven’t used React in a couple years.

  • cornflour@lemmy.ca
    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@lemmy.ca
        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.