DEV Community: Jan Zimprich

Stop shipping dashboards. Ship the ability to make one.

Jan Zimprich — Thu, 30 Jul 2026 14:39:18 +0000

Every internal app I have ever worked on has the same bug, and it is not in the code.

It ships one dashboard for twelve departments. Controlling wants margin per region. Support wants the last five tickets of exactly one customer. The warehouse wants one number, large enough to read from across the hall. So the screen becomes a compromise, and everybody quietly learns to ignore eighty percent of it. Then we bolt on filters. Then saved views. Then a report builder with forty fields that three people ever open.

The view is wrong because it was decided months before the question was asked.

So I stopped shipping the view. In DRYL the app now ships the ability to make one — in the moment, in the words the person already uses. This post is about the three pieces that took it from a party trick to something I would put in front of a finance team: the canvas, the document, and the dock — plus the voice session that turned out to be the most fun part to build.

The canvas is a document, not generated markup

DrylAiCanvas renders a CanvasSpec: a tree of typed nodes. The model does not emit HTML, and it certainly does not emit Razor. It emits this:

{
  "id": "revenue",
  "type": "lineChart",
  "data": { "source": "sales.byMonth", "params": { "year": 2026 }, "refresh": "interval:30s" }
}

The type comes from a closed catalog — stack, grid, card, tabs, accordion, form, stat, kpi, table, dataGrid, timeline, the chart family, markdown, list, keyValue, code, emptyState, plus the interactive ones: inputText, textarea, select, slider, toggle, button. Each renders through the same components the rest of the app is built from, so a generated view is not a second design system with worse spacing.

An unknown type or an invalid prop does not break the screen. It renders as a placeholder, and the validation failure comes back to the model as a plain corrective sentence it repairs on the next turn:

Artifact created: 14 elements, 3 inputs. Some elements were invalid and are shown
as placeholders — fix via update_artifact: unknown data source 'sales.byQuarter'.

That loop is most of why this works. The model is authoring a document in a vocabulary I control. It is not writing my frontend.

The model never touches your numbers

This is the constraint everything else hangs off: a model that writes numbers into a chart is a demo, not software.

Data sources are registered at startup. The model sees a name, one sentence of description, a parameter schema derived from a record, and the result shape. It never sees a row.

public sealed record SalesParams(int Year, string? Region = null);

builder.Services.AddDrylCanvasDataSource("sales.byMonth",
    "Revenue per month in thousands of euros.",
    async (SalesParams p, CanvasDataContext ctx, CancellationToken ct) =>
    {
        var db = ctx.Services.GetRequiredService<AppDb>();
        var rows = await db.SalesAsync(p.Year, p.Region, ct);
        return CanvasData.Series(rows.Select(r => r.Month), ("Revenue", rows.Select(r => r.Total)));
    });

ctx.Services is the circuit's scope. Tenant and signed-in user are resolved there and never travel through the spec, which means the model cannot influence them by writing a clever prop. The worst a hallucinated binding can do is name a source that does not exist — and that is a corrective sentence, not an incident.

Actions work the same way, with one extra rule I am fond of:

builder.Services.AddDrylCanvasAction("order.approve",
    "Approves an order. Asks the user to confirm.",
    async (ApproveArgs a, CanvasActionContext ctx, CancellationToken ct) => { /* … */ });

The AI may place a button and label it. It may never press one. Only a user press runs a command. There is no code path where the model triggers an action, and that is a structural property, not a prompt instruction.

`CanvasDocument` — the part that makes it software

A view that dies on F5 is a demo. CanvasDocument is the snapshot that survives a reload, a user switch and a deployment.

var doc = CanvasDocument.Capture(workspace, "Monday morning", form);
await store.SaveAsync(doc);
// …later, on another machine, after a deploy
doc.Restore(workspace);

Four decisions in there that I would defend in a code review:

Bindings travel; numbers do not. A restored document asks the registered sources for fresh values. A document is never a stale copy of a database — it is a saved question, not a saved answer. Open Monday's board on Thursday and it is Thursday's data.

Reading is gated on a schema. TryFromJson is the only entry point, because that is where the version check lives. A document written by a newer build is refused with a sentence a human can read, instead of half-deserializing into something subtly wrong.

AsTemplate(title) gives you the same views with no store id and a new title. That is how an app ships its standard dashboards: the team's "Monday morning" board becomes a starting point people fork and bend, instead of a screenshot in Confluence.

Live form values fold in. At capture, what the user has typed is folded into the nodes' value props; interactive nodes seed themselves from that prop on restore. The half-filled form comes back half-filled, and the loading path contains not one line about it.

And a small one: views that are mid-exit animation are skipped. What is animating away does not belong in a document.

The dock is the medium

The thing you change the document through is DrylCanvasDock, and the design brief was one sentence: a command bar, not a chat.

The artifact is the answer. The text beside it is not, so it does not get to own half the screen. One input, one live status line — Building · 7 elements — and the full transcript only if you ask for it.

Two details worth stealing:

The dock lives in the browser's top layer (popover="manual"), because a position: fixed element is measured against the nearest ancestor with a transform or backdrop-filter — which, in an app made of glass cards, is essentially always some card. If your floating panel has ever mysteriously clipped, that is why.

Selecting an element on the canvas puts a context chip in the dock and prefixes your next sentence with the node's id, type and label. So "make it a bar chart" lands on the right node instead of on the model's best guess. The update then streams in as a patch: ops applied one per 260 ms beat, so a change reads as choreography rather than a flicker. One operation, one movement.

And then you just talk to it

The newest piece: DrylVoiceRun. You press the microphone in the dock and the dock becomes the conversation — composer, chips and suggestions step aside for an orb and the last line that was said.

The audio never touches .NET. The browser holds a WebRTC peer connection straight to the realtime API. Routing audio through a Blazor Server circuit costs a few hundred milliseconds in each direction, which is precisely the difference between a conversation and a walkie-talkie.

The server's job is one HTTP call: mint an ek_… client secret that expires in 60 seconds with the entire session baked into it. The browser never sees the API key, and it cannot change the model, the instructions or the tool list — those are inside the minted token.

Tool calls come back over the data channel and land in C#:

[JSInvokable]
public async Task<string> OnToolCallAsync(string callId, string name, string argumentsJson)
{
    var tool = Options.FindTool(name);          // only what the host registered
    if (tool is null) return Fail($"Unknown tool \"{name}\".");
    var result = await tool.InvokeAsync(ParseArguments(argumentsJson));
    return result as string ?? JsonSerializer.Serialize(result);
}

The browser only ever supplies a name. What runs is whatever the host put in the list, so a manipulated page cannot invent a tool. And it never throws: a model waiting for a result that never arrives stops mid-conversation with no way back, while an error it can read keeps it talking.

Hand it the same tool list the text agent has — including create_artifact, update_artifact and open_view — and the loop closes. You say "show me last quarter by region, and put yesterday's open orders next to it", and while you are still finishing the sentence the chart is drawing itself and a second view is opening beside the first.

Two more things I would do again:

The voice maps onto the library's existing five AiState values — Listening / Thinking / Speaking become Active / Thinking / Streaming. No new vocabulary. The whole UI breathes in one language, so you can feel where the AI is working without reading a label.

The input level is deliberately not in .NET. A level that updates 30 times a second and raises a state-change event is 30 renders a second for a decoration. It stays in the browser and drives a CSS variable on the orb.

What this actually changes

Not "AI in your app" as a chat bubble in the corner that summarizes the page you are already looking at. The canvas is the surface, and the assistant is how you reshape it. The screen stops being a compromise between twelve departments and starts being the answer to the question one person has right now — and then, if it turns out to be a good screen, they save it and it becomes part of the app.

Honest limits, because I would want to know them:

The catalog is closed by design. It will not render your arbitrary component. That is the price of the model never being able to break the UI.
A generation costs a second or two. Choreography helps; it does not make it instant.
Data sources and actions need curating. A vague description is a bad UI, reliably. This is the new "naming things".

DRYL is open source, Blazor Server and WebAssembly, zero npm packages. The canvas lives in DRYL.Components and the agent side in DRYL.Components.Agents.

👉 components.dryl.dev

If you build something with it — or break it in an interesting way — I would genuinely like to hear about it.

Streaming AI straight into Blazor UI: typed structured generation and live AI-built dashboards

Jan Zimprich — Wed, 22 Jul 2026 20:23:22 +0000

Most AI UIs today are the same thing: a chat bubble filling up with Markdown. That's fine for text — but your app isn't made of text. It's made of cards, charts, badges, timelines, forms.

So I built DRYL — an open-source, AI-native component library for Blazor (Server & WebAssembly) — around one idea:

The AI shouldn't stream strings at your users. It should stream UI.

In this post I want to show you the two features I'm most excited about:

DrylAiGenerate<T> — typed structured generation that streams a partial object into real Blazor components, token by token.
DrylAiCanvas — the model builds a live, interactive dashboard as a chat artifact, and clicks inside it route back to the model.

(All GIFs below are recorded from the live docs at components.dryl.dev — no mockups.)

The problem with streaming text

Token streaming is a solved problem for chat. But the moment you want the model to produce something structured — a recipe, a product draft, a report — you usually end up with one of these:

Wait for the full JSON, deserialize, then render. The user stares at a spinner for 20 seconds.
Stream Markdown and lose all structure — no charts, no badges, no forms, no interactivity.

What you actually want: the model emits JSON for your C# type, and your UI renders the object while it's still incomplete — title appears first, then the description grows character by character, then list items pop in one by one.

That's exactly what DrylAiGenerate<T> does.

Typed structured generation: `DrylAiGenerate<T>`

You define a plain C# record:

public record Recipe(
    string Title,
    string Description,
    int Minutes,
    int Serves,
    List<Ingredient> Ingredients,
    List<Step> Steps);

Ask the runner for a stream (it sets a JSON-schema response format for T and yields raw tokens):

// Works with any Microsoft.Agents.AI provider — OpenAI, Azure, Ollama, ...
_stream = Runner.GenerateStreamingAsync<Recipe>(agent, session, prompt, aiKey: "recipe");

And bind it to your UI:

<DrylAiGenerate T="Recipe" Source="_stream" Key="recipe">
  <ChildContent Context="snap">
    <DrylCard Ai="@snap.State">
      <h3>@snap.Value?.Title</h3>
      <p>@snap.Value?.Description</p>

      <DrylTimeline>
        @foreach (var step in snap.Value?.Steps ?? [])
        {
          <DrylTimelineItem Title="@step.Title">@step.Text</DrylTimelineItem>
        }
      </DrylTimeline>
    </DrylCard>
  </ChildContent>
</DrylAiGenerate>

snap is a GenerationSnapshot<T>: on every chunk you get the best-possible partial Recipe. Under the hood a tolerant PartialJsonReader<T> repairs the incomplete JSON on the fly — half-open strings, unclosed arrays, truncated objects. If a chunk lands mid-token and the parse fails, it simply holds the last good snapshot. No flicker, ever.

A few things I care a lot about here:

It's typed. No dynamic, no JObject spelunking. snap.Value is your Recipe, IntelliSense and all.
It's just an IAsyncEnumerable<string>. No SDK lock-in in the component — in the docs the same demo runs against a canned replay and a real local model via Ollama. Tests don't need a model at all.
The UI knows the AI is working. Every DRYL component accepts a shared AiState (Thinking / Streaming / Generated). Pass Ai="@snap.State" and the card wears a breathing gradient aura while streaming and plays a one-shot reveal when done. One vocabulary across the whole library — users feel where the AI is at work without reading a label.
Progressive disclosure is trivial. Wrap sections in DrylPresence gated on the partial value (Visible="@(snap.Value?.Ingredients is { Count: > 0 })") and each part of the card animates in the moment the model produces it.

The showstopper: `DrylAiCanvas` — AI-built interactive artifacts

Structured generation renders your layout. The canvas goes one step further: the model designs the layout.

DrylAiCanvas gives your agent two tools — create_artifact and update_artifact. When the user asks for something visual, the model streams a component spec (a curated tree of DRYL components: charts, stat tiles, tables, inputs, buttons) and the canvas builds it node by node, live, next to the chat:

<DrylChat> ... </DrylChat>

<DrylAiCanvas Run="_run"
              OnInteraction="i => Send(i.ToPromptMessage())" />

var tools = DrylCanvasTools.Create(_run);
var agent = new ChatClientAgent(chatClient,
    instructions: "...", tools: tools.All);

Here's the part that makes it more than a pretty renderer: the artifact is interactive, and interactions round-trip to the model.

Buttons inside the artifact carry an intent. When the user picks a region in the generated filter and clicks "Break down by region", you get a CanvasInteraction — including the current values of every form control in the artifact. interaction.ToPromptMessage() turns it into the next chat turn; the model answers with update_artifact, streaming a patch. Changed nodes glow, new nodes glide into place (FLIP-animated — nothing snaps), untouched nodes stay put.

So the loop is:

user asks → model builds UI → user clicks inside that UI → model updates it.

That's the "artifacts" experience you know from modern AI chat apps — as a drop-in Blazor component, running on your own agent and your own components.

Safety-wise: the model never emits HTML or code. It emits a JSON spec validated against a curated component whitelist. Invalid nodes never render — the model gets a corrective error string and retries.

The rest of the iceberg

These two are my favorites, but the AI layer runs deeper — all speaking the same AiState vocabulary:

DrylAiStream — token streaming into DrylMarkdown with a paced smooth mode (some providers deliver tool-call turns in one burst; this keeps it reading as a stream).
Human-in-the-loop tools — ready-made AIFunctions that pop real dialogs mid-run (AskChoice, AskText, RequestPermission) and await the user's answer.
Display tools — the model answers with live charts, stat rows and timelines inline in the conversation (show_line_chart, show_stats, …).
DrylHandoffTrace — multi-agent sequential/concurrent flows rendered as a living timeline.
DrylAiField — wrap any input, get an unobtrusive ✨ affordance: generate into an empty field, or transform just the selected text.

And underneath it all sits a full general-purpose component library (60+ components): glass surfaces, token-driven dark/light modes, a fixed motion vocabulary, container-query responsiveness, zero npm dependencies.

Try it

Docs & live demos: components.dryl.dev — the AI demos on the site run against real streams
Source: github.com/Zimpi/DRYL.Components
NuGet:

dotnet add package DRYL.Components          # core library
dotnet add package DRYL.Components.Agents   # AI layer (Microsoft Agent Framework bridge)

builder.Services.AddDrylComponents().AddDrylAgents();

The core is stable and dependency-free (Markdig only); the agents package is experimental and versioned independently while the Microsoft Agent Framework itself matures. You bring your own AIAgent — OpenAI, Azure, or a local Ollama.

If you're building anything AI-flavored in Blazor, I'd genuinely love feedback — especially on the canvas spec format and what components you'd want the model to be able to build. Issues and PRs welcome. ⭐