Loading
Show that work is in progress while keeping the interface stable and usable
Put loading feedback near the operation that started it. Preserve useful content and keep unrelated actions available. The person should know what is happening and whether they need to wait.
Reserve the shape of the expected content so the controls around it do not move.
Illustrative example · Reduced motion: choose a state to compare.Choose the signal
| Situation | Starting treatment |
|---|---|
| A button starts a short request | Show the button's loading state and retain its width. |
| A region is fetching its first content | Reserve the expected space and name what is loading. |
| Existing content is refreshing | Keep it visible and identify that an update is in progress. |
| A long operation reports real progress | Show the completed amount and total, with a useful unit. |
Use LoadingSpinner for an indeterminate wait. Give its surrounding status a useful name, such as “Loading entities” or “Saving changes.” If the server cannot report progress, use an indeterminate indicator instead of an invented percentage.
Keep the task stable
Prevent duplicate submissions while a write is pending. Keep the action's label and layout stable enough that nearby content does not jump. Reserve space for predictable content such as avatars or list rows.
For background refreshes, explain whether the previous content is still usable. A new filter request must not be overwritten by a slower response for an older filter. See Filtering & Sorting.
Completion, cancellation, and failure
End the loading state on success, failure, and cancellation. Show the saved result or an error with recovery. Offer cancellation for long-running work when the application can honor it, and explain whether partial results will remain.
Announce meaningful status changes through a suitable live status region. Avoid announcing every animation frame or repeatedly replacing the same message. Use a stable text status when reduced motion is enabled.
Check a fast response, a slow response, a rejected request, navigation away, and a repeated click. Each should leave the interface in a state that matches the operation's outcome.
Last updated on 2026-10-31
Was this page helpful?