shadcn.io is not affiliated with official shadcn/ui
Developer Tools Settings Block for React
Four SDK switches and an environment choice beside a request panel they steer: capture lists six requests, choosing one opens its JSON, and debug, verbose errors and timing each add their own part to what it shows.
Installation
Overview
Show what each debugging switch does, with this developer tools panel for React with Base UI. Inside a hairline frame with a plus mark on each corner, a column of Switch rows (Debug mode, Verbose errors, Performance timing and Capture requests) and a Segment Group for the environment, Sandbox or Live, sit beside the panel they steer. Live prints a one-line problem that it changes real data. Capture requests says "Turn on Capture requests" in an Empty state until it is on, then lists six typed requests in a native table (method, path, status and time); choosing one opens its JSON in a JSON Tree View below. Each other switch changes what shows: Debug mode adds a debug object, Verbose errors adds the stack to a failed request, and Performance timing fills the time column and adds a timing breakdown that adds up to it. 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 capture panel stacks under the switches and the foot stays pinned to the bottom of the screen. It's built from Switch, Segment Group, Empty, JSON Tree View, Button, Shine Button and Guides, with a CSS entrance only. For SDK and API consoles, mobile developer settings and any debugging page.
FAQ
How do I show my own requests?
Edit CALLS: each request has an id, a method and path, a status, the time in milliseconds, the body it sent and the response it got, and, for a failed one, an error and a stack. payloadOf builds the JSON from a request and the switches, and phasesOf splits the time into phases that add up to it, so a new request needs no other change. ENVIRONMENTS holds the host each environment shows in the URL.
What does each switch change?
Capture requests decides whether the panel lists requests at all. Debug mode adds a debug object (the SDK version, retries and whether the request was queued) to each request's JSON. Verbose errors adds a stack to the error of a request that failed; a request that succeeded has no error to add it to. Performance timing fills the time column, which shows a dash while it is off, and adds a timing object whose parts add up to the total. The environment changes the host in each URL.
Why does Live show a problem?
Because the switches stop being a sandbox exercise: on Live they would apply to real devices and real data, so the line says so before you save. It is a statement rather than a block, and Save still works; add a confirmation of your own if saving on Live should need one. The line's room is reserved in both environments, so choosing Live doesn't move the switches.
What stays local, and how do I wire it for real?
The six requests are typed: nothing is captured from a device and nothing is sent. Save keeps the switches in this page and says so. To make it real, have the SDK send its recent requests to this panel (or read them from your log store), apply the switches to the SDK's configuration on save, and keep the JSON keys you want to show in payloadOf.
How do a keyboard and a screen reader use the panel?
Each switch has its name, the environment is a labelled group, and the request table is a native table with a caption and a header row. Each request is a button, so Tab reaches it and Enter chooses it; the status line says which request is shown, and the JSON tree below it is a real tree with arrow-key navigation. A request that failed carries a "failed" mark in words as well as its icon, and a time of a dash says "Timing is off" for a screen reader.
How does it look on a phone?
The switches come first at full width, then the capture panel at a fixed height with the table above and the JSON below, each scrolling inside its own box, so choosing a request or switching capture off never changes the height of the panel. Paths are cut short with an ellipsis in the table and shown in full in the JSON.
Related
- Pro
Error Reporting Settings
Alerts and auditAn error grouping panel that leads with a tester: paste an error message and it says whether the rules would drop it, group it under a named group or start a new one, beside tabs of grouping rules, ignore patterns and sample rates.
- Pro
API Key Builder Settings
API and webhooksAn API key settings panel with a table of keys, a builder that sets None, Read or Write for each resource, and a try-a-request check that answers Allowed or Denied with the reason before anything is saved.
- Pro
API Rate Limit Tiers Settings
API and webhooksA matrix of API limits with the plans across and a number field in every cell, a daily capacity worked out under each plan and a guard that stops a higher plan from allowing less than the plan before it.
- Pro
CORS Allowed Origins Settings
API and webhooksA CORS settings panel that checks its own origin list for four unsafe patterns, each with a Fix button that rewrites the list, plus origin rows with an environment tag, a validating add form and a policy band for credentials and preflight cache.
- Pro
OAuth Apps Settings
API and webhooksAn OAuth apps settings window with a list of registered apps beside the chosen app's client ID, a masked secret with a confirmed Roll secret, redirect URIs that are checked when added, and grouped scopes with the consent sentence they produce.
- Pro
Rate Limiting Settings
API and webhooksA 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.