shadcn.io is not affiliated with official shadcn/ui
Role-Based Comments Block for Svelte
Six roadmap comments read through a View as control for Viewer, Editor, Admin and Owner, where comments above your role collapse into one placeholder row and the visible count follows.
Installation
Overview
Show each person only the comments their role may read, with this role-based comment thread for Svelte with Ark UI. A compact header names the review and holds a "View as" Segment Group with four roles: Viewer, Editor, Admin and Owner. Under it a hairline frame holds six comments on a Q4 roadmap in a labelled scroll region that keeps its height. Each comment carries the lowest role that may read it, written as a lock chip ("Editors and up", "Admins and up", "Owner only"), and the thread is worked out from that typed minimum. Comments above the chosen role are not drawn: one placeholder row of the same height says how many are hidden and which roles can read them ("2 comments need Admin or Owner"), and the count line follows ("3 of 6 visible"). Changing the role moves nothing else on the page, and a polite status line says what you can read now. It is built from Segment Group, Avatar, Badge and Guides, with a CSS entrance only. For team docs, project spaces and any thread where some remarks are not for everyone.
FAQ
How do I set who can read what?
Edit ROLES and COMMENTS. ROLES runs from the lowest role to the highest and a role reads everything at or below it. Each comment has an id, its author, an ISO at, its body and min, the id of the lowest role that may read it. visibleOf and hiddenOf work out the list, the placeholder row and the count from those two arrays, so adding a role or a comment needs no other change.
Is this a real permission check?
No. The View as control is a viewing aid for the page: it only changes which typed comments are drawn, and the placeholder row says so in a note under the thread. In a real app the server decides what each person may read and never sends a comment above their role at all. The hidden rows here exist only on the client, so do not use this pattern to protect data.
Why one placeholder row instead of one lock per comment?
A lock row per hidden comment leaks how many there are and who wrote them, and it makes the list a different length for every role. One row names a count and the roles that can read them, takes the height of a comment and stays last in the list, so switching role never makes the page jump. The thread also sits in a region of fixed height.
Is it accessible?
The role control is a labelled group of four options that works with the arrow keys. The thread is an ordered list in a labelled region you can reach with Tab and scroll with the arrow keys, each comment names its lock in words with an icon, and the status line is present from load and read out politely when the role changes. No meaning rests on colour.