When to use Suspense vs startTransition?

[shrutikapoor08]

I see that some examples shared in the discussions have UI intensive tasks, and therefore marked in startTransition, such as
this example by Swizec.

1. Are there use cases where it makes sense to put a fallback component in Suspense vs marking UI updates in startTransition? Is there a best practice approach of choosing one vs the other or should these be used together?

2. In an API heavy app, eg: infinite image scrolling app such as Instagram, how do we determine if a task should have a fallback component or be wrapped inside startTransition? Example codesandbox here

[dai-shi]

Quoting a comment here as it seems more relevant.
#86 (reply in thread)

Especially this one:

And the idea is that nearly all transitions are triggered by a router.

I felt like I had a wrong mental model, because I thought I would be using useTransition for fetching data in background. (Assuming Suspense for Data Fetching lands.)
So, the questions are:

• Would startTransition be something primarily used in (router) libraries?
• Are there any use cases for app developers to use it?

[dai-shi]

Quoting again from a different thread: #100 (reply in thread)

The problem is that today startTransition isn't great to put in router or other top-level code because it would opt in entire page transitions into concurrency. Which contradicts the "gradual opt-in" strategy. So we had to explain it through a more "local" example.

This is interesting to know. So, because React 18 introduces "gradual" concurrent rendering, instead of "full" concurrent mode, the use case of startTransition becomes limited. In other words, if an app developer confirms the full compatibility with concurrent rendering, startTransition pattern works okay.

[lunaruan]

Hey! That’s a great question! These two APIs are designed for different use cases and can absolutely be used together. There are two kinds of scenarios at play:

• Load - when you initially load data on an unloaded page (ex. navigating to a new page). Suspense is a way to specify fallbacks instead of content, so it should used in this case.
• Refresh - when you load new data on a page that has already loaded (ex. tab navigations or pull to refresh interactions). In this case, it's bad to hide something the user has already seen because it's disruptive. In this case, startTransition lets you avoid retriggering Suspense boundaries that have already been shown, so you can avoid replacing existing UI with a fallback.

For example, consider an App with a Homefeed and a Profile page. The app is wrapped in a Suspense boundary with a loading spinner fallback. When you first load the Homefeed, we will initially render a loading spinner while the page waits for data. If you then navigate from Homefeed to Profile:

• Without startTransition, Suspense will blow away the already loaded Homefeed page and show the loading spinner again while we wait for Profile data, which is a disruptive user experience.
• With startTransition, we can avoid retriggering the Suspense fallback boundary and keep showing the Homefeed page (possibly, with some separate indicator) until we get the initial Profile data.

Because startTransition only avoids retriggering Suspense boundaries, new Suspense boundaries will still be shown. This is because we don't want to make users wait until we've fetched all new data to see content.

So in the example above, if you have a Suspense boundary around your friends list in the Profile page, users can view the rest of the page while the friends list loads.

[alvarlagerlof]

This is the best explanation I've seen yet. I think i finally understand.

[Sardor-M]

You saved my day, thanks for your neat explanation.