Skip to content
shadcn.io

shadcn.io is not affiliated with official shadcn/ui

Delegation Task List Block for Radix UI

A hand-off tracker where you delegate tasks from a select, see each chain with a due date and check-in, and switch View as to accept or decline with a required reason.

Framework
UI library

Preview

Preview width

Installation

Part of Pro
Pro unlocks the code and one-line install of every Pro button and text effect, plus the MCP for your AI editor.
Have Pro already? Sign in to open it.Opens here as soon as you're Pro.

Overview

Pass work to a teammate and see it come back answered, with this delegation to-do list block for React with Radix UI. A Segment Group in the header switches View as between Maya, who owns the tasks, and Jonas, who receives them, and Jonas carries a count of what is waiting. As Maya, each task shows its chain (two initials in Avatar tiles and an arrow), a state Badge with a glyph and a word (Waiting, Accepted, Declined), the due date, a check-in date a working day before it, and a Native Select to delegate it to someone else or keep it. As Jonas, a waiting task offers Accept, the first of them a Shine Button, and Decline, which opens a Textarea for a reason that can't be left empty. A declined task returns to Maya with the reason on its row. The list sits in a fixed-height scroll region with an Empty state, so switching sides never moves the foot, and Guides rule the bands. For hand-offs between people, team leads and any list where someone else's answer matters.

FAQ

How does View as work, and is anything really sent?

One page plays both sides. The Maya and Jonas segments change which tasks are listed and which actions each row offers; no message, email or notification leaves the page. The status line says so after each action ("Nothing was sent"), and the foot repeats it.

Why must Decline have a reason?

A decline without a reason leaves the owner guessing, so the reason field is required: sending it empty shows a problem under the field and keeps focus there. A sent reason is shown on the task for both sides, and the task goes back to Maya, who can delegate it again.

Where do the due date and the check-in come from?

Each task has a typed ISO due. The check-in is worked out from it by checkInOf: one working day earlier, so a Monday looks back to Friday. Labels such as "Overdue 1 day" or "Fri 16 Oct" are worked out from one fixed AS_OF constant, never the visitor's clock, so the server and every browser print the same words.

How do I change the people and tasks?

Edit PEOPLE (an id, two initials and a name) and START. A task holds to (a person's id, or an empty string while the owner keeps it), state (none, pending, accepted or declined) and the dates. The names are invented; replace them with your own users and keep the initials short.

What stays local, and how do I make it real?

Everything: the tasks live in React state and reset when the page reloads. In a real app, save from pick, accept and send, notify the other person there, and read the "waiting" count from your server so the Jonas segment is true for each signed-in user.

How does it look on a phone?

The View as control sits under the sentence, each row stacks its select or buttons under the title and chain, and the decline field opens inside the row. The list region keeps its height, so nothing under it jumps.