Skip to content
shadcn.io

shadcn.io is not affiliated with official shadcn/ui

Effective Priority Table Block for React

A ticket queue where a switch raises any ticket due within two days by one level, shown as drawn bars, a word and a raised-from note, and the Priority head sorts by that effective rank.

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

Rank a queue by what is worth doing first, with this effective priority table for React with Base UI. A compact header holds a Switch, "Raise one level when due within 2 days", over one framed panel with a plus mark on each corner and a native table of eight tickets. Priority is a word and four drawn bars, one to four filled in foreground weights, never colour. With the switch on, a ticket due within two days of the day the list was taken (counted from 9 Oct, a typed date) is worth one level more: it reads "High", an up arrow and "raised from Normal", and a band over the table counts them ("3 raised, sorted by priority, highest first"). The Priority head is a button that sorts by that effective rank rather than by the word, highest first, then lowest first, then the order the tickets arrived in, and ties fall to the earlier due date. A ticket already at Urgent stays there. On a phone the assignee, with an Avatar on larger screens, and the due date fold under the title. It's built from Switch, Avatar and Guides, with a CSS entrance only. For support queues, issue trackers and any list ranked by a rule that can change.

FAQ

How do I fill it with my own tickets and rule?

Edit TICKETS: each has an id, a title, an assignee, a base priority from 1 to 4 and an ISO due date, in the order the tickets arrived. AS_OF is the day every count starts from, and WINDOW is how many days from due lifts a ticket. The rule itself is lifted, one small function, so a different rule (lift only Normal, lift two levels) is a change in one place. The bars, the word, the "raised from" note, the count and the sort order are all worked out from base, due and the switch.

What does the sort use, and how are ties settled?

The Priority head sorts by the effective priority, the one after the switch is applied, so a Normal ticket raised to High sorts with the High ones even though its word starts with N. The first press gives highest first, the second lowest first and the third puts the tickets back in the order they arrived. Tickets with the same effective priority are ordered by the earlier due date, then by their number, so the order never depends on the browser. Turning the switch re-ranks the list in the sort that is active.

What stays local, and where does the date come from?

Everything is in the page and nothing is stored: the switch, the sort and the raised tickets reset on reload. "Due in 2 days" is counted from the typed AS_OF date, never from the clock, so the demo reads the same on any day. In your app pass today's date to daysLeft, and send the switch to your server if the rule should apply to everyone, not just this view.

Is it accessible, and does a raised ticket rely on colour?

No colour carries the priority or the raise: a word, a count of bars, an up arrow and the words "raised from Normal" say it. The switch is named by what it does, the Priority head is a real button with aria-sort on its column (none while the tickets are in their arrival order), and a polite status line, present from the start, reads the raised count and the order after each change. The table is native, with a caption, column heads and the ticket as a row header. Nothing moves under the pointer: the order changes on a press.

Do the rows change height when a ticket is raised?

No. Every priority cell keeps a second line, empty until a ticket is raised, so a row is the same height with the switch on or off, and the rows are rebuilt in their new order rather than sliding past each other. The status line reserves two lines on a phone for its longest sentence.

How does it look on a phone?

The table keeps Ticket and Priority. The assignee and the due date fold into the line under the title ("QH-318, Nuala Brightman, due Oct 11"), and the priority cell wraps its "raised from" note instead of truncating it. The switch sits under the header's sentence with its label beside it.

  • Pro

    Sortable Members Table

    Sort and search

    A members table whose column heads are buttons: press one to sort, again to reverse, a third time for the original order, with aria-sort on the active head, ties settled by name and a spoken line for each result.

  • Pro

    A customer segments table ordered by a two-rule sort builder: pick a column and a direction for the first rule and for the tie-break, see the order as a 1 and a 2 on the heads, and Reset to start again.

  • Pro

    Chip Filters Table

    Sort and search

    A bug table beside a rail of chip filters for priority and status: chips in a group are or, the groups are and, every chip counts what it would show, and an empty state clears them all.

  • Pro

    A library catalogue table with a search field and an availability menu: typing keeps the titles whose name or author holds the words and marks them, the foot says how many match, and an empty state under the head clears the search.

  • Pro

    Empty States Table

    Sort and search

    A contact book table with two empty states you reach by doing something: searching for text that is not there, and removing every contact after a confirm, then adding the samples back, all at one fixed height.

  • Pro

    Dependency Updates Changelog

    Packages and versions

    A table of eight dependency updates in two groups, Production and Dev: package, old and new version, the kind of bump and a three-pip risk, with sortable heads that reorder the rows inside each group.