shadcn.io is not affiliated with official shadcn/ui
Subscribe Updates Changelog Block for Ark UI
A changelog split with an email form at the start (a field that checks itself, an Every release or Weekly digest choice and a Shine Button) and the three latest releases at the end.
Installation
Overview
A subscribe-to-releases changelog for React with Ark UI, written for Tidingwell, a fictional product-update tool. A split with a solid divider that runs from the page's top rule, with a + where it meets the halves. At the start sit the title, one sentence and the form: an email field, a two-way choice of how often (Every release or Weekly digest) and a Shine Button, the block's one primary action. At the end, "Recent changes" lists the three latest releases, each with a type tag (an icon and a word), version, day, linked title and sentence, then a View all releases link. Submitting checks the address: an empty or malformed one says what is wrong in a line that is always there, so the button never moves, and keeps focus in the field. A valid one clears the field and a polite status says what would happen next. Nothing is sent in this demo. On a phone the form comes first and a rule separates the halves. 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 Field, Input, Toggle Group, Shine Button, Badge, Button and Guides, with your theme's tokens for every colour. For product changelogs and release hubs that want a sign-up beside the latest work. The releases are example data.
FAQ
Where does the address go?
Nowhere: this is a demo, and the confirmation says so. In submit, after the checks, there is a comment where you send email and frequency to your mailing-list provider or your own endpoint. Keep the sentence about the demo only while that is true. The field is cleared after a valid submit; the confirmation repeats the address so the reader can see what was typed.
How is the address checked?
On submit only, with a small shape check (problemWith): something, an at sign, something, a dot, something. An empty field and a malformed one have different messages. The message sits in a line under the field that is always rendered, with a hint in it until there is an error, so the layout never shifts and the button doesn't move between press and release. Typing clears the message. A real address can still bounce: confirm it by email, as any sign-up should.
What do Every release and Weekly digest change?
They are two options of a single-choice group that is never empty: one is always pressed, and a pressed option is the text colour on the page colour. The choice only changes the confirmation's wording here. Edit FREQUENCIES to add a third, such as a monthly summary; each has an id, a label and a short phrase (gist) used in the confirmation.
How does it work with a keyboard and a screen reader?
Tab goes to the email field, the choice group, the Subscribe button and then the links. The arrow keys move between the two options. After a failed submit focus returns to the field and the error is tied to it with aria-describedby; the confirmation is a status region that is present from load, empty, and filled after a valid submit, so it is read once.
Where do the links go?
Each title and View all releases are links with href="#": point them at the release pages and your full changelog.
The View all releases button takes asChild with the link inside, so it can be your router's link.
How does it fit on a phone and in a right-to-left layout?
Below lg the halves stack with the form first, a rule between them, and the Subscribe button takes the full width. Nothing scrolls sideways at 320 pixels. In a right-to-left layout the divider, the arrow on View all releases and the rows mirror, while the version numbers stay left to right.