shadcn.io is not affiliated with official shadcn/ui
Resolvable Threads List Integration Block for Svelte
An integration list section for a preview-review tool reading comments on a Vercel preview: a derived merge verdict with a progress bar, then thread rows with overlapped initials, a page path, the first words and a Resolved checkbox.
Installation
Overview
An integration list section for Svelte with Ark UI, written for Stagehouse, a fictional tool for reviewing preview deployments, and its Vercel connection. A compact header carries the mark pair at its end. Under a band rule, a verdict is worked out from the threads ("3 open threads: merge blocked", or "All resolved: merge allowed") beside a count and a thin bar of how many are resolved, and a polite status line that is in the page from load. Then six comment threads run as rows rail to rail: an overlapped pair of initials for who wrote, the page path in code, the first words of the thread and a Resolved checkbox. Ticking one lowers the open count and the verdict follows; the rows never move, and a resolved row only softens its text. Nothing is sent to Vercel or to a pull request. The page's rails and top rule come from the Guides spine, so it lines up with its neighbours in a stack. It's built from Guides, Checkbox and Progress with your theme's tokens for every colour. Vercel is named in text only: no Vercel logo, colour or wordmark ships with the block. The threads, people and paths are example data.
FAQ
Where do the threads come from, and how do I change them?
They are typed example data in THREADS: two authors, a page path, the first words and whether the thread starts resolved. The open count, the verdict, the progress bar and the sentences in the status line are all worked out from the ticks. Wire the list and the ticks to your own comments and nothing else needs editing.
Does it really block a merge?
No. The block only shows the rule: while any thread is open, "merge blocked", and when all are resolved, "merge allowed". Nothing is sent to Vercel or to a pull request. Your product decides what the verdict does, for instance by reporting a pending or a passing status on the pull request.
How do screen readers get who wrote what?
The initials are decoration and hidden; each thread's text starts with the two authors' names, visually hidden, so it reads "Ines V. and Tomas O. wrote: ...". Each checkbox is named by its visible word "Resolved" and the page path, so it reads "Resolved /pricing". The verdict and the status line are real text and the status line is a polite live region.
How does it fit a phone?
The path moves under the first words of the thread and the checkbox stays at the end of the row; the initials stay at the start. Nothing scrolls sideways. On a wide screen the path gets its own column.
What stays local?
Everything: ticking a thread is page state, and the status line says so from load, then names the page of the thread you changed.
How does it behave in right-to-left layouts and with reduced motion?
The columns mirror; page paths keep their own direction, and the counts and the verdict sit in their own isolates. The only motion is the header's fade-up on load, which reduced motion turns off. The checkboxes are the same on every framework and library apart from how each one reports a change.