rfc: Adopting Async React in React Aria Components by devongovett · Pull Request #9894 · adobe/react-spectrum

devongovett · 2026-04-08T23:57:03Z

View Rendered RFC

Comment here

This PR also includes a prototype implementation in several components for discussion.

rspbot · 2026-04-09T00:21:08Z

Build successful! 🎉

rspbot · 2026-04-15T00:54:00Z

Build successful! 🎉

rspbot · 2026-04-15T19:31:47Z

Build successful! 🎉

rspbot · 2026-04-23T03:30:43Z

Build successful! 🎉

LFDanLu · 2026-04-23T17:35:00Z

+function Example() {
+  return (
+    <ListBox>
+      <ListBoxSuspense
+        // Initial loading state
+        fallback={<ProgressCircle />}
+        renderError={error => `Error loading data: ${error}`}>
+        <Page url="https://pokeapi.co/api/v2/pokemon" />
+      </ListBoxSuspense>
+    </ListBox>
+  );
+}


so just to verify the API: as mentioned below about the composability, a user who wants to have sections that each load from a different data source and have individual spinners would have separate <ListBoxSuspense>s wrapping a different <Page> (or w/e they would call it in their implementation), and each Page would be a Collection that renders that individual section and its async loaded items? I guess the top level suspense wouldn't be necessary unless they wanted a spinner to wait for all of the section to do an initial load?

yeah exactly. if you wanted a single loading state for all sections, you'd wrap the suspense around the entire list. If you wanted separate loading states for each section, you'd wrap suspense around each section individually.

Hm, I'm kinda wondering about the styling logistics of that. Loader items typically consume very little height, so one would likely always trigger multiple section loads when reaching the end of the first section, while you would typically only want to load the successor? Can probably be solved with styling in userland, but wondering whether there should maybe be something more intuitive to account for that.

As I've done in this example with the Page component, you could nest them so that the second section only loads after the first one (if it is in view). Whether you want parallel or sequential loading, separate or a single spinner, is all up to the application / design requirements.

LFDanLu · 2026-04-23T17:43:24Z

+
+* Do pending states make sense in all of these components? Supporting these within Spectrum will require input from design.
+* How do we want to support pending states that aren't displayed as a progress bar / spinner (e.g. a "shimmer")? We may need to announce something, even if a progress bar is not present in the DOM.
+* How do we want to handle components that have both a loading state for data and a pending state for an action? For example, Select and ComboBox support loading states for their list of items, but may also support a changeAction when the user selects an item. Would these both display the same spinner UI?


ideally, I think we'd want this to be customizable by the user, so perhaps we have additional render props along side isPending/or some way of informing the user what triggered said pending state?

LFDanLu · 2026-04-23T17:45:40Z

+* Do pending states make sense in all of these components? Supporting these within Spectrum will require input from design.
+* How do we want to support pending states that aren't displayed as a progress bar / spinner (e.g. a "shimmer")? We may need to announce something, even if a progress bar is not present in the DOM.
+* How do we want to handle components that have both a loading state for data and a pending state for an action? For example, Select and ComboBox support loading states for their list of items, but may also support a changeAction when the user selects an item. Would these both display the same spinner UI?
+* For components with multiple actions, do we want individual pending states (e.g. `isChangePending`, `isSubmitPending`) or a single pending state that aggregates these?


I think I'd lean towards an aggregated pending state for now?

nwidynski · 2026-04-23T21:17:23Z

+    });
+  }, [setControlledValue, setOptimisticValue, setOptimisticError, changeAction]);
+
+  return [optimisticValue, isPending, setValue, optimisticError];


nit: https://react.dev/reference/react/useActionState has the isPending ordered after the setter, might want to do the same?

nwidynski · 2026-04-23T22:16:05Z

+function Example() {
+  return (
+    <ListBox>
+      <ListBoxSuspense
+        // Initial loading state
+        fallback={<ProgressCircle />}
+        renderError={error => `Error loading data: ${error}`}>
+        <Page url="https://pokeapi.co/api/v2/pokemon" />
+      </ListBoxSuspense>
+    </ListBox>
+  );
+}


Hm, I'm kinda wondering about the styling logistics of that. Loader items typically consume very little height, so one would likely always trigger multiple section loads when reaching the end of the first section, while you would typically only want to load the successor? Can probably be solved with styling in userland, but wondering whether there should maybe be something more intuitive to account for that.

nwidynski · 2026-04-23T22:21:13Z

+## Open Questions
+
+* Do pending states make sense in all of these components? Supporting these within Spectrum will require input from design.
+* How do we want to support pending states that aren't displayed as a progress bar / spinner (e.g. a "shimmer")? We may need to announce something, even if a progress bar is not present in the DOM.


It would have to be a user-supplied component or a very generic announcement though, right? Otherwise how would we pull the appropriate context/msg for announcement?

Generic announcement is better than no announcement. We could at least use the accessible name of the element that's pending so it could announce something like "Save, pending" if the button's label was "Save". For a more contextual message, perhaps a prop.

Sure, but that is only if the pending element has an accessible name in the first place. This is the case with all components that useLabel currently, which is mostly fields, but for the ones that dont it might be difficult / breaking to require? Also see this somewhat related issue I opened a while back #7240 (comment)

All components that would support a pending state already require some kind of accessiblity label. Even components that don't use useLabels internally still have a visible label / aria-label.

The vast majority of the proposed ones yeah, because as I meant, they are mostly fields. Some of them are exceptions though, e.g. Tabs, ToggleButton and Disclosure, which neither have a default aria-label nor enforce presence of a aria-label prop or visible label. That can probably be worked around though with some sane defaults, so its not a strict blocker.

All of those require visible labels (children) / aria-labels too. We might not always emit a warning ourselves (that can be improved) but accessibility checkers like aXe definitely will.

github-actions Bot added the RAC label Apr 8, 2026

devongovett changed the title ~~Async react~~ rfc: Adopting Async React in React Aria Components Apr 8, 2026

github-actions Bot added the S2 label Apr 15, 2026

devongovett force-pushed the async-react branch 2 times, most recently from 738e9d9 to f08bc63 Compare April 15, 2026 18:50

Base automatically changed from checkbox-field to main April 23, 2026 00:07

devongovett added 12 commits April 22, 2026 20:21

Support actions in Button and ToggleButton

5971b01

TextField and SearchField

5f074ab

Implement in more components

288db48

add RFC

b454fac

fix jest config

8375543

Check if useOptimistic exists as well

630fbaa

wip: Experimenting with error handling

d79e068

fix types

0e0f6b6

add examples

aa6f5b4

prototyping form actions

5d00b8e

fix test

666d776

Add suspense example

ec5a08a

devongovett force-pushed the async-react branch from 51e810e to ec5a08a Compare April 23, 2026 03:22

LFDanLu reviewed Apr 23, 2026

View reviewed changes

nwidynski reviewed Apr 23, 2026

View reviewed changes

Conversation

devongovett commented Apr 8, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

rspbot commented Apr 9, 2026

Uh oh!

rspbot commented Apr 15, 2026

Uh oh!

rspbot commented Apr 15, 2026

Uh oh!

rspbot commented Apr 23, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

devongovett Apr 24, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

nwidynski Apr 24, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

devongovett commented Apr 8, 2026 •

edited

Loading

devongovett Apr 24, 2026 •

edited

Loading

nwidynski Apr 24, 2026 •

edited

Loading