What this prompt does
This prompt sets the model up as a senior .NET engineer and asks for working Blazor component code with a real file layout, not sketches. You choose [mode] (Server or WebAssembly), name the [metrics] to display, and set the [data_source], and it returns a component tree from page to chart, real-time updates over SignalR with reconnect handling, a chart component bound to the live stream, a debounced filter panel, CSV export of the filtered view, and auth with role-gated sections.
The structure works because it addresses the trap that sinks Blazor Server dashboards: chatty SignalR traffic that melts under real load. By asking for reconnect handling and debounced filters from the start, the prompt produces something that survives more than a demo. [mode] decides whether you get Server or WebAssembly patterns, [metrics] defines what the charts render, and [data_source] (for example, SQL Server via EF Core) grounds the server-side queries that feed the live stream. Asking for the component tree before the code is what keeps the output coherent — you see how the page, filter panel, chart, and hub relate before you read a single @code block, which makes the individual files much easier to slot into place.
When to use it
- You're building an admin or metrics dashboard in Blazor and want a real component tree.
- You need real-time chart updates over SignalR with proper reconnect handling.
- You want a filter panel that re-queries server-side and debounces input.
- You need CSV export of whatever the user has currently filtered.
- You want auth with ASP.NET Identity and role-gated sections wired in.
- You're deciding between Blazor Server and WebAssembly and want the matching patterns.
Example output
Expect the component tree first — page down to chart, with @code blocks and parameters — then the key files with code: the page, the SignalR hub, the chart component bound to the live metric stream, the debounced filter panel, and the services. CSV export and role-gated auth sections are included. The reconnect logic is part of the real-time wiring, not an afterthought.
Pro tips
- Pick
[mode]deliberately; Server keeps logic on the backend but is more sensitive to SignalR load, while WebAssembly shifts work to the client. - Name concrete
[metrics]so the chart components and queries are specific rather than placeholder. - Set
[data_source]to your real backing store so the server-side filter queries match your schema. - Load-test the live update path before calling it done; Blazor Server demos hide the SignalR cost that real traffic exposes.
- Keep the filter debounce in place — removing it is what turns a smooth dashboard into a query storm.
- Ask it to add a second chart afterward to confirm the component tree and live-stream wiring generalise.
- Verify the CSV export reflects the active filters, not the full dataset, since exporting everything is rarely what a filtered view implies.
- Test the role-gated sections with a non-privileged account; auth that only ever gets exercised as an admin hides gaps until the wrong user finds them.
