[WIP] Add async transitions to React 19 docs

[rickhanlonii]

trafficstars

Preview

This isn't final, I'm still iterating on the best way to explain this so please resist the urge to share as if it's the actual explanation

Overview

This PR updates the useTransition docs to include async transitions.

• Reworks existing content that says it's only sync
• Adds example of creating an action
• Adds troubleshooting for set state after await
• Adds troubleshooting for out-of-order requests

[vercel[bot]]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
19-react-dev	✅ Ready (Inspect)	Visit Preview	💬 2 unresolved ✅ 18 resolved	Dec 4, 2024 9:11pm
react-dev	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Dec 4, 2024 9:11pm

[vercel[bot]]

@rickhanlonii is attempting to deploy a commit to the Meta Open Source Team on Vercel.

A member of the Team first needs to authorize it.

[tom-sherman]

To be honest I really don't see async transitions (with useTransition) being practically adoptable without the race condition handling built in. Without this, they are simply a target for libraries as the queue handling is very tricky.

There are so many footguns with using them on their own that I think there needs to be some massive disclaimer, and for them to be called out as a tool for library and framework authors.

[rickhanlonii]

@tom-sherman it's going to be more common for app developers to use useActionState or use components with an action prop like <form> to create an Action, instead of using raw transitions directly. Using async transitions directly is targeted to library developers who intend to write their own queuing logic or component library authors to expose an action prop.

[rickhanlonii]

It's similar to how doing event handlers to submit data on your own is tricky (for example, this case isn't handled in a raw event handler either), and libraries make that easier using raw events and exposing props to limit the complexity to app developers.

[rickhanlonii]

Converting back to WIP, I think there is a better way to explain this.

[rickhanlonii]

Updated this page based on feedback, some notable changes:

• An Action is not just an async transition, you can have sync actions too (like mutations to local data that doesn't need a network request). The new framing is that the function passed to startTransition (sync or async) is the "action" and by convention if a function is called inside startTransition then it's called an "Action".
• Added "Perform non-blocking updates with Actions" to explain actions
• Added "Exposing action prop from components" to explain how to expose an action prop
• Removed "Marking a state update as a non-blocking Transition ", since there's already a section below for "Building a Suspense-enabled router" for navigation, but I think we need a new usage example for this.
• Updated all the examples with the proper action naming and to use use