Error / permission / offline

Preview

Local preview. It doesn't affect real accounts, environments, or run data.

Usage

• Show the cause of a failure with the possible next steps.
• A temporary request failure leads to retry, and a lost connection leads to retry after reconnecting. Restricted access leads to restoring access, and a bad address leads to browsing the list.
• Keep drafts, and mark cached data as stale. Clear the cache when access is lost or the resource can't be found.
• The example combines InlineMessage, EmptyState, Field, Button, Collapsible, and CodeBlock, and settles a local Promise manually. Complete each response to inspect every recovery state.

• Don't turn errors into empty results or success. Show the error with its recovery action.
• Don't infer server availability from offline status alone. Confirm it with a real request.
• Don't leave unauthorized data or secrets in error details, the clipboard, or the cache.
• Don't present canceling as a rollback of server work.
• Don't rely on the example's local simulation of restoring access and reconnecting. The product owns real requests, retry counts, backoff, idempotency, online events, access requests, and server permission checks.

Anatomy

Failure/result preview controls → controlled draft Field → state-specific InlineMessage or EmptyState + recovery action → optional cached data with freshness status → safe collapsible diagnostics → outcome announcement

Keyboard and accessibility

• The state selector keeps focus. Starting a retry moves focus to Cancel, and canceling returns focus to the draft input.
• Success moves focus to the result heading, and a failed retry moves focus to Retry. Restricted access moves focus to the restore access button.
• Restoring access moves focus to the refetch data button and doesn't count as immediate success.
• The details disclosure and copy messages follow their primitives' keyboard rules.
• Errors use role=alert. Progress and recovery results use status announcements.

Give each control a name that describes its purpose. Connect error messages to their controls, and signal state with more than color. Automated checks don't replace manual keyboard and assistive technology testing.

Example code

Shared components take their styles from design tokens. Each example sets its own composition and accessibility attributes. The calling screen defines callbacks, refs, and product data.

import { InlineMessage, Button, EmptyState } from '@surflane/ui'

<InlineMessage.Root tone='danger' role='alert'>
  <InlineMessage.Content>
    <InlineMessage.Title>The request failed</InlineMessage.Title>
    <InlineMessage.Description>
      Your draft is retained.
    </InlineMessage.Description>
    <InlineMessage.Actions>
      <Button onClick={retry}>Retry</Button>
    </InlineMessage.Actions>
  </InlineMessage.Content>
</InlineMessage.Root>

// Request ownership remains in the product:
// guard duplicate starts synchronously; snapshot the draft; use AbortController.
// accept a response only if its identity is still current and not aborted.
// preserve draft on failure/cancel; clear protected caches on permission changes.
// restore meaningful focus and report freshness without implying successful mutation.
// diagnostics must be safe to display/copy and contain no credentials.

Key API

The table lists the common wrapper's main props. See the package type declarations for the full types.

Related tokens