shadcn.io is not affiliated with official shadcn/ui
GitHub Stats Integration Block for React
An integration stats section for a release-notes tool reading from GitHub: cycle time by repository as stacked bars of four stage medians on a shared scale, a legend, the total hours at the end of each row, and a headline worked out from the data.
Installation
Overview
An integration stats section for React with Base UI, written for Mergequill, a fictional tool that drafts release notes from merged pull requests, and its GitHub connection. A compact header ("Cycle time by repository") has a worked-out headline ("loom-api is slowest at 51 hours, mostly waiting for review") and the mark pair at its end. Under a band rule, a legend names the four stages (Coding, Waiting for review, Review, Merge) with a tone each and a line on where it starts and ends. Below it, five repositories are rail-to-rail rows, longest first: the name and the stage that takes most of the time, one stacked bar of the four stage medians in four foreground tones on a scale shared by every row, the total hours at the end, and the four numbers in words under the bar. The last row ends the block, so no rule closes it. The page's rails and top rule come from the Guides spine. It's built from Guides and plain CSS bars, with your theme's tokens for every colour. GitHub is named in text only: no GitHub logo, colour or wordmark ships with the block. Nothing is read from GitHub, and the repositories and hours are example figures.
FAQ
How do I change the figures?
Edit REPOSITORIES at the top of the file: each repository has a name and the median hours of its four stages (coding, waiting, review, merge). The row order (longest first), the shared scale, every bar width, the totals, the stage named in each row and the headline sentence are all worked out from that list, so there is nothing else to keep in step. Rename or add stages in STAGES and partsOf.
Are these real cycle times, and how is the total worked out?
They are example figures; the block reads nothing from GitHub. Each bar adds up the median hours of four stages, which is a typical pull request rather than the median of totals, and the header says "adds up each stage's median". In a real product, compute each stage from the timestamps GitHub gives for commits, review events and merges, and feed the same typed shape.
Why do all the bars share one scale?
So repositories can be compared by eye: the longest total fills the bar and every other bar is its share of it, so a short row stays short. A segment's width is its hours over that longest total, set through a CSS variable.
How is it read by screen readers, and what about colour?
Tone carries the order of the stages, never hue, and the bars are decorative and hidden from assistive technology. Every row says the same facts in words: the repository, the total, the stage that takes the most, and the four stage numbers ("Coding 9, Waiting for review 14, Review 5, Merge 1"). Each repository name is an h3.
How does it fit on a phone, in right-to-left layouts and with reduced motion?
On a phone each row keeps the name and the total on one line, with the bar full width under them and the four numbers wrapping below. Bars always run left to right (they are a quantity, not text) while the rows themselves flip in a right-to-left layout; names and numbers keep their reading order. The segments grow in once on load; reduced motion draws them at their final size.
Related
- Pro
Can and Cannot Detail Integration
Scopes and stepsAn integration detail section for a release-notes tool installing on GitHub: a header with the mark pair and Install on GitHub, then two columns sharing a divider, the read-only permissions it uses and the ones it has no access to.
- Pro
GitHub Grid Integration
Cards and previewsAn integration grid section for a release-notes tool reading from GitHub: five check rows with a switch each, and a drawn pull request box whose merge button reads Merge or Waiting on a count of checks as you switch them.
- Pro
GitHub List Integration
Synced tablesAn integration list section for a release-notes tool reading from GitHub: fourteen pull requests under a segmented Open, Merged and Closed filter with derived counts, branch pills, check dots, release-note state, and a working Retry on the one row that failed to sync.
- Pro
GitHub Setup Integration
Guided stepsAn integration setup section for a release-notes tool installing on GitHub: a progress strip and three bands to pick an account from radio cards, choose All or Only select repositories, and tick repositories under a Free plan limit of five, with Finish setup that waits for a valid choice.
- Pro
AWS Stats Integration
Bars and columnsAn integration stats section for a cloud cost tool reading from AWS: six region lanes on one 0 to 24 hour ruler showing how far each region's cost data runs behind, with a solid tick at the 6 hour agreement.
- Pro
Datadog Alert Dedupe Stats Integration
Bars and columnsA usage section for a post-incident review tool connected to Datadog: seven day columns, each a tall light bar of alerts received with a short solid bar of the incidents opened inside it, and a closing band of three figures.