Result Page

Demo & usage

More examples

<sv-result status="error" title="Something went wrong" description="We couldn't load this page. Try again.">
  <sv-button label="Retry" (clicked)="reload()" />
</sv-result>

<!-- Bind the error and the page shows its correlation id with a copy
     button. "It said something went wrong" is an unanswerable ticket;
     the same sentence with a reference is one log query, and the id was
     already on the error - toSvDataError() reads it out of the body or
     the x-request-id header.

     focusHeading moves focus to the title on arrival: a routed error
     page otherwise leaves focus on whatever the user clicked, often an
     element that no longer exists.

     showDetails adds a collapsed Status/Code block - for an internal
     tool or a staging build. The error's "cause" is never rendered
     anywhere: it is a raw thrown value, and this is a screen people
     photograph. -->
<sv-result
  status="error"
  title="Could not load the report"
  [description]="error()!.message"
  [error]="error()"
  [focusHeading]="true"
  [showDetails]="isInternalUser()"
  retryLabel="Try again"
  [retryAction]="reload" />

<!-- A slotted button is right for "go home" — a link cannot fail. The
     retry is the one action that can, repeatedly, so it is first-class:
     [retryAction] makes the component own it, which means a second press
     is refused, the button shows a spinner, and a second failure is
     rendered instead of vanishing. Without the action, (retry) is emitted
     and the pending state is yours. -->
<sv-result
  status="error"
  title="Could not load the report"
  retryLabel="Try again"
  [retryAction]="reloadReport"
  (retryFailed)="logFailure()">
  <sv-button label="Back to dashboard" svResultActions />
</sv-result>

When to use

• Showing the outcome of a flow on its own screen: success, error, warning, info.
• Post-checkout, post-submit, 404/500 pages, access-denied screens.
• For an empty list within a page, use the Empty State instead.

Async states

• error
• retry

Outputs

Customization & theming

• Pick a `status` (success, error, warning, info, empty) for the semantic icon and color.
• Diagnostics from the error itself: bind `[error]` and the server's correlation id renders with a copy button — "it said something went wrong" is an unanswerable ticket, and the same sentence with a reference is one log query. `[showDetails]` adds a collapsed status/code block for internal surfaces. `cause` is never rendered: it is a raw thrown value, and an error page is a screen people photograph.
• `[focusHeading]` moves focus to the title when the page appears, which is what a routed error page owes a keyboard or screen-reader user — the SPA swapped the view and left focus on an element that no longer exists. Opt-in, because `sv-result` is also used inline, where stealing focus interrupts something else.
• Override the glyph with `icon` (an icon-library name) and choose a `size`.
• Project body content and action buttons into the result slots.
• A first-class retry: `retryLabel` renders the button, `[retryAction]` hands the work to the component (first-wins, so repeated presses are refused; a spinner and `retryPendingLabel` while it runs; the rejection rendered under the button), and `(retry)` / `(retryFailed)` report what happened. Built on `createAsyncAction` in `@styloviz/core`.

Best practices

• Don't: Don't put raw diagnostics in `description` or the default slot — stack traces, SQL, internal hostnames, upstream status codes. Both are free-form and ungoverned, so nothing stops you; an error page is one of the most-screenshotted surfaces in any app.
• Do: Give the user one copyable reference — a correlation or request id — instead. It converts an unsupportable ticket into a log query, and it discloses nothing.
• Do: Map `status` to the real outcome so icon and color reinforce the message.
• Do: Give users a next step (primary action) rather than a dead end.
• Do: Use `retryLabel` with `[retryAction]` instead of a slotted retry button. A slotted button has no pending state, so it can be pressed repeatedly with no feedback — firing the request that just failed again and again.
• Tip: Keep the title outcome-focused and the description actionable.

Accessibility

• Status icons are decorative; the title carries the meaning as a heading.
• `[focusHeading]="true"` gives the title `tabindex="-1"` and focuses it once on arrival — `-1` so it does not become a permanent tab stop. Without it a routed error page leaves focus wherever the user clicked, often on an element that no longer exists, so the next Tab starts at the top of the page and a screen reader announces nothing.
• The copy confirmation is announced as well as shown: a sighted user sees the label change to "Copied", and an `aria-live="polite"` region says so for everyone else.
• Action buttons are labelled and keyboard reachable.
• Adequate contrast across statuses in light and dark.
• The retry button carries `aria-busy` and is disabled while its action runs, so a screen-reader user is not told to press a button that is already working.