Comment Thread

Demo & usage

More examples

When to use

• Displaying discussion threads with nested replies and reactions.
• You want inline reply, emoji reactions and relative timestamps out of the box.
• For inline @-references inside a single field, use the Mention input.

Async states

• loading
• empty
• error
• retry

Item identity & owned state

Restorable state

• busyIds

Bind these to put a saved view back — the open sections, the hidden columns, the selected rows — and read their Change events to store what the user does.

Server writes

Writes

• react

Each payload carries a requestKey — send it with the request so a retry cannot apply the same change twice.

Rollback

Call event.rollback() when the save fails — the change is already on screen, and this is what puts it back.

While saving

Bind busyIds — with two writes outstanding there is no single state to roll back to, so the action stays locked until the first one lands.

On failure

Pass the failure to error to show it in place — without taking away what the user was working on.

Outputs

Wire it to your API

This component is headless about transport: it renders what you give it and reports what the user asks for. Nothing below requires @styloviz/data — drive it from whatever you already use.

• This component does not emit a query, so it renders what you give it. Fetch on your own trigger and bind `comments`, `loading` and `error`.
• Set `filtered` when a search or filter is active. It is the difference between "you have no orders" and "no orders match this filter" — telling a customer with 4,000 orders the first one reads as a bug.
• The load-level retry is `retryLoad` here, because `retry` already means a per-item action on this component.
• Normalize failures with `toSvDataError()` from `@styloviz/core`. It derives `retryable` from the status, so a 404 does not get a "Try again" button that can only fail again.

Full walkthrough: Connecting to a backend.

Customization & theming

• Cap nesting with `maxDepth` and toggle the inline `showReplyBox`.
• Identify the viewer via `currentUserId` to reveal inline Edit and Delete on their own comments.
• Handle `reply`, `react`, `edit` and `delete` outputs to persist changes.
• Reactions are optimistic: the pill and its count move on press and are reconciled against the next `comments` value you supply, so nothing has to be re-rendered to make a press feel immediate.
• `busyIds` locks one comment's controls mid-write and reaches nested replies automatically; `error` reports a failed action above the thread, `loading` / `loadError` / `retryLoad` cover the fetch.
• Comment bodies wrap long words and URLs (`break-words`) so they never overflow the bubble on narrow screens.
• A `review` variant renders comments as product reviews (star rating, verified-purchase badge and helpful votes); the Comment type gains `rating`, `verified` and `helpfulCount`.
• `deleted: true` renders a tombstone in place of a comment — withheld content and identity, no actions, timestamp kept, replies intact — and `deletedMessage` supplies the wording.
• `commentErrors` is a map of comment id to failure, rendered beside that comment and passed down to nested replies; `error` stays for a failure that belongs to no comment on screen.

Best practices

• Do: Limit nesting with `maxDepth` so deep threads stay readable on mobile.
• Do: Pass `currentUserId` so edit/delete only appear on the viewer's own comments.
• Do: Bind `busyIds` whenever you handle `react`. It locks the comment while its write is in flight, which is the only thing that keeps `rollback()` unambiguous — and it is passed down to nested replies for you.
• Do: Call `rollback()` from the error branch of the reaction write. The pill has already moved; nothing else puts it back.
• Do: Send `requestKey` with the write and have the server ignore a key it has already applied. An interceptor that retries a timeout otherwise turns one reaction into two.
• Do: Apply the event's `reacted` / `count` when the write succeeds rather than toggling what is in your array, so the same answer arriving twice cannot invert it back.
• Don't: Don't expect the pill to wait for your array. It moves on press, and the value you hand back next is what wins — so a `react` handler that does nothing leaves the pill showing an unsaved reaction forever.
• Don't: Don't use `error` for a failed fetch. It renders above a thread that is still there; `loadError` replaces the thread and carries its own retry.
• Do: Mark a parent `deleted: true` and leave it in the array when it has replies. Removing the node removes the replies, which is other people's writing.
• Do: Prefer `commentErrors` over `error` for anything that failed on a comment that is on screen — a reply, an edit, a delete, a reaction. It puts the message beside the button that caused it instead of a screenful away, and two failures no longer overwrite each other.
• Do: Report a delete failure through `commentErrors` (or `error`) rather than silently leaving the comment in place. It is also what returns focus to the Delete button that was pressed.
• Don't: Don't move focus yourself after `delete`. The component waits until your array no longer contains the comment, then lands on whatever took its place — moving focus at emit time parks it on a button that is about to disappear.

Accessibility

• Reaction toggles expose `aria-pressed` and a descriptive label (emoji + count), so state is not conveyed by color alone — and both track the optimistic value, so the announced state matches what is drawn.
• A comment in `busyIds` disables its pills, Delete and Send and marks them `aria-busy`, so an in-flight write is announced rather than only implied by an unresponsive button.
• Opening reply or edit moves focus into the textarea, which carries an explicit label; Edit exposes `aria-expanded`.
• Timestamps expose readable values and avatars fall back to initials with an accessible name.
• Focus is never dropped: posting a reply returns it to that comment's Reply button, saving or cancelling an edit returns it to Edit, and a failed delete returns it to Delete. Each of those controls destroys the element that had focus, and the browser's only fallback is the top of the page.
• A confirmed delete moves focus to the comment that took its place — the previous one when the last comment goes, the thread itself when none is left — and announces the removal in a polite live region, since a comment simply ceasing to exist is otherwise silent.