shadcn.io is not affiliated with official shadcn/ui
GDPR Consent Settings Block for React
A purposes register with a legal basis, retention and consent record per purpose, a rule that withdrawing must be as easy as giving, and three data requests counted down from 30 days.
Installation
Overview
Keep a register of why a product holds data, with this GDPR consent settings block for React with Base UI. Above the register a strip of three cells lists the data requests that are due (access, erasure, portability) with their reference, the day each is due and how many of the 30 days have gone, drawn as a hairline bar and spelled in words, with a Mark done Button that turns into Reopen. The register is a native table with a row per purpose (account and billing, product analytics, marketing emails, security logging, support): its data as outline Badges, a legal basis and a retention in Native Selects and, where the basis is Consent, the consent record (the text's version, its date and how many people are on it) with the way people withdraw. Giving takes one step, so a way to withdraw that takes more, or none, is a problem on the row and Save refuses it with a Shine Button and moves focus to it. Under 1024 pixels each purpose becomes a card. It's built from Native Select, Badge, Button, Shine Button and Guides, with a CSS entrance only. These are samples, not legal advice. For a privacy platform, an admin settings area or any product that records consent.
FAQ
How do I fill the register and the requests?
Edit PURPOSES (a name, the kinds of data and, for consent, the record: the text version, when it was published and how many people are on it), SAVED (each purpose's basis, retention and withdrawal route) and ASKS (a reference, a kind and the ISO day it arrived). Days to go are the 30 allowed minus the days between the arrival day and the typed AS_OF date, in UTC, so they read the same everywhere and never follow the clock.
What does as easy to withdraw as to give mean here?
Giving consent takes one step in this sample (one tick at sign-up), so the rule is that withdrawing may not take more. A press in settings or a link in each email takes one step and passes; asking support takes three and is flagged ("Withdrawing takes 3 steps."); no way at all is flagged ("Consent needs a way out."). The row says "Giving: 1 step. Withdrawing: 3." beside the select so the comparison is visible before the problem is.
What does Save do when a row has a problem?
It refuses. The status line says how many rows need fixing, focus goes to the first one's withdrawal select, and nothing is saved until every consent row can be withdrawn in one step. With no problems it keeps the register in this page's state and says how many changes it saved, or that there was nothing to save. Discard puts the saved register back. Mark done and Reopen on the requests apply at once and don't wait for Save.
What stays local, and how do I make it real?
Everything. Nothing is stored, sent or recorded: the register, the requests and the consent counts live in this page and return to their starting values on reload. To make it real, keep the register on your server, record each consent with its text version and timestamp when it is given or withdrawn, and compute the people on record from those records instead of typing the number.
How do the selects work by keyboard?
They are native selects, so they open with the keyboard and the browser's own picker, each named for its purpose ("Legal basis for Marketing emails"). Changing the basis to Consent shows the withdrawal route and the record in the same space, so the row keeps its height, and changing it away replaces them with a short note.
How does it look on a phone?
Below 1024 pixels each purpose is a card: its name and data, the basis and retention side by side, then the consent area, with a visible label over each select. The requests come first, one compact card each with the Mark done button at its end, and the Save and Discard foot stays pinned to the bottom of the screen.
Related
- Pro
Cookie Consent Settings
Privacy and consentA cookie preferences page with four purpose cells on shared hairlines: necessary locked on in words, three switches, and under each the exact cookies it covers, kept for how long, set or blocked.
- Pro
Privacy Settings
Privacy and consentA privacy panel with three presets that set five switches, a sentence that adds them up, and a row per setting that says in words what it means for you and what it shares.
- Pro
Compliance Controls Settings
Privacy and consentA policy review window: a rail of six sample policies grouped Overdue, Due soon and Current, and a pane with owner, cadence, the next review worked out from a typed date and who has acknowledged.
- Pro
Data Classification Settings
Privacy and consentA four-label ladder (Public, Internal, Confidential, Restricted) as columns of handling switches, with six sample documents whose label is checked against what it requires.
- Pro
A person's consent choices as an accordion of purposes with switches beside a consent receipt, an ordered log that gains a line for each choice and saves as a real PDF or JSON file.
- Pro
Profile Settings
Privacy and consentA profile visibility page: five parts of a profile, each with a menu for who sees it (Everyone, Workspace, Only me), beside a drawn profile card with a Preview as choice (Public, Teammate, Me) that hides what that viewer cannot see.