shadcn.io is not affiliated with official shadcn/ui
Rate Limiting Settings Block for React Aria
A rate limit you can try: a framed strip replays one client's 24 requests over 10 seconds against the chosen algorithm, limit, window and burst, marking each request allowed or rejected and counting both.
Installation
Overview
Show what a limit does before it ships, with this rate limiting panel for React with React Aria. Inside a hairline frame with a plus mark on each corner, a framed strip replays the same 24 requests from one client over 10 seconds: each request is an upright tick, solid on the top lane when it is allowed and hollow on the lower lane when it is rejected, with the verdict over it ("16 allowed, 8 rejected") and the first rejection named. Beside it, a Native Select chooses the algorithm (a fixed window, a sliding window or a token bucket), a Number Input sets the limit, a second Native Select the window and a Slider the burst allowance, and a sentence says what that amounts to. Every change replays the same traffic, so the algorithms can be compared on one burst; a fixed window draws its edges, and the burst that straddles one gets through twice. The last band counts unsaved changes in a status line beside a Shine Button to save them and an outline Button to discard them. On a phone the strip comes first. It's built from Native Select, Number Input, Slider, Button, Shine Button and Guides, with hand-built bars and a CSS entrance only. For API gateways, developer platforms and any setting where a number only makes sense next to the traffic it governs.
FAQ
How is each request judged?
By a plain function over the typed requests, run in order. A fixed window allows a request while fewer than the limit have been allowed in its window, and starts the count again at each window edge. A sliding window allows it while fewer than the limit were allowed in the window's length just before it. A token bucket starts full, refills at the limit divided by the window, and spends one token for each request it allows. The burst allowance is the most requests accepted in the same second for the two windows, and the size of the bucket for the token bucket. The result is worked out on every render, so the ticks, the counts and the sentence always agree.
How do I use my own traffic?
Edit REQUESTS, a list of millisecond offsets from the first request, and AXIS_MS, the length of the strip. Keep the ticks at least 200 ms apart so the hollow marks don't overlap at 320 px. SAVED is the setting the account has stored when the page opens, and ALGORITHMS and WINDOWS fill the two menus.
Is the strip accessible?
The ticks are decoration: the strip is one image named with the whole result (the algorithm, the counts and the first rejection), and the same facts are written next to it as text, with the counts in large figures. A rejected request differs from an allowed one by lane and by shape, a hollow bar under the line, so nothing relies on colour. The time axis is drawn left to right in every language, because time on it runs one way.
What stays local, and how do I wire it for real?
All of it. Nothing is limited, counted or sent: Save keeps the setting in this page and says so, and the requests are typed. To make it real, send the saved algorithm, limit, window and burst to your gateway, and feed the strip your own recent requests for a client instead of the typed ones. Run the same decision on the gateway, so what the strip shows is what clients get.
What do Save and Discard do?
The block keeps two copies of the setting, the saved one and the one being edited, and counts how many of the four controls differ ("2 changes not saved yet."). Save makes the edited copy the saved one; Discard puts the saved copy back and redraws the limit field. Both stay in place and focusable while nothing changed, marked aria-disabled, and say so when pressed. React Aria's number field commits on blur, Enter or an arrow key rather than on every keystroke, so the strip replays when you leave the limit field.
How does it look on a phone?
The strip and its verdict come first, so the effect of a change is on screen above the controls that make it, and the controls stack under it at full width. The sentence under the controls reserves its room, so a longer one never moves the foot, which stays pinned to the bottom of the screen while you scroll.