this post was submitted on 09 Jul 2023
10 points (100.0% liked)

React

935 readers
1 users here now

A community for discussing anything related to the React UI framework and it's ecosystem.

https://react.dev/

Wormhole

[email protected]

Icon base by Skoll under CC BY 3.0 with modifications to add a gradient

founded 1 year ago
MODERATORS
 

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!

top 5 comments
sorted by: hot top controversial new old
[โ€“] [email protected] 8 points 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.

[โ€“] [email protected] 3 points 1 year ago (1 children)

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 ๐Ÿ˜…

[โ€“] beefsquatch 1 points 1 year ago (1 children)
[โ€“] [email protected] 1 points 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.

[โ€“] [email protected] 1 points 1 year ago

Suspense seems to be great and solve the issue of many loading states but at least with my use cases, I'd use it in a project where I need data to be fetched and libraries like SWR don't look like they will be supporting it anytime soon.