Proposal: a shadcn-style component registry + drift-aware CLI for Fluent Blazor — the missing half of "bring your own theme," and the unlock for AI-generated UI

[buvinghausen]

TL;DR

You've already solved the hard, unglamorous half of a modern design system: a full, granular design-token layer that most component libraries never bother to expose properly. The half that's still missing is the distribution model — the shadcn-style "copy the source into my repo, I own it, tell me when upstream drifts" workflow. Closing that gap would do more than improve DX; it would make Blazor + Fluent 2 the natural target for AI coding tools, which is almost certainly something Microsoft wants and doesn't yet have.

This is a discussion-starter, not a spec. I've tried to be honest about the parts that are genuinely hard (shadow DOM, the consistency-vs-ownership philosophy) rather than hand-wave them.

---

The half you've already nailed (and most libraries never do)

Credit where it's due — this is the part everyone underestimates:

• 160+ granular design tokens surfaced as first-class, injectable services, not a frozen theme object.
• FluentDesignTheme for declarative, layout-level configuration, plus per-element SetValueFor targeting.
• A source generator for strongly-typed token classes.
• All of it riding on FAST's Adaptive UI so accessibility and contrast survive customization.

Genuinely: the "bring your own tokens" story here is ahead of a lot of the React ecosystem. The token plumbing is done. That's the expensive part, and it's finished.

The half that's missing: the shadcn distribution model

shadcn/ui won the mindshare war not because the components are prettier, but because of how they're delivered:

1. You own the source. npx shadcn add button copies editable source into your repo. No package dependency, no version lock-in, no hidden abstraction. The file is yours the moment it lands.
2. Drift detection built in. shadcn add --diff shows what changed upstream since you last pulled, so you merge improvements deliberately instead of being silently overwritten — or silently stuck.
3. A registry, not a package. Components are registry.json / registry-item.json items served as plain JSON over HTTP. There are namespaced registries (@acme/button), private/authed registries, and — importantly — the registry format is explicitly framework-agnostic. It is not a React-only idea. It ships "any file types."
4. An MCP server ships with the CLI, and tools like v0 read/write the component source directly.

Point 4 is the whole ballgame. AI agents are good at shadcn because the component is legible source the model can read and edit, plus a machine-readable registry describing what exists and how it composes. That's the loop you don't have yet.

Why this is a Microsoft-shaped opportunity

Here's the strategic argument, stated plainly:

• The default output of nearly every AI UI tool today is React + Tailwind + shadcn. That's the format models were trained on and the format registries speak.
• That means the entire "vibe-coded app" pipeline currently flows away from Blazor by default. A dev prompts an agent, gets shadcn/React, and never touches Fluent.
• A Fluent registry + drift-aware CLI + an MCP server flips that. It gives agents (a) editable Razor/Fluent source they can scaffold, and (b) a component-level mapping — Button → FluentButton, shadcn tokens → Fluent tokens — so an agent can port a shadcn-shaped app onto Blazor + Fluent 2 as a first-class skill.
• The payoff is exactly what Microsoft is presumably after: Blazor adoption + Fluent 2 as the AI-era default design language, instead of ceding both to the React/Tailwind stack.

You've built the design system. This is the delivery mechanism that lets AI tools reach for it.

What it would concretely require

Roughly, adapting the shadcn toolchain to the .NET world:

• Tokens as a portable source of truth. A style-dictionary-style pipeline that emits your Fluent tokens to multiple targets (CSS vars, C# constants, a JSON manifest agents can read). You already generate typed token classes — this is a generalization of that, made consumable outside the library.
• A registry format. A registry.json equivalent describing components, their token dependencies, and composition — served as static JSON. Framework doesn't matter to the schema; that's the point.
• A "copy-local + drift" CLI. Either a dotnet global tool (dotnet fluent add datagrid, dotnet fluent diff) for people who live in the .NET toolchain, or an npm-based CLI that reuses shadcn's own registry plumbing so it's instantly familiar to the AI-tool ecosystem. (An honest question below: NuGet vs. dotnet-tool vs. npm.)
• An isolated component workbench. A surface where each component renders on its own, driven live by the token layer — the human-readable face of the registry and the fastest way to close the customization gap that keeps surfacing in these discussions. The point isn't a specific tool; it's the notion: see a component in isolation, watch tokens flow through it, read the emitted token manifest, copy it out.
• An MCP server that exposes the registry + token manifest + the React→Fluent mapping to agents.

The idea, visualized — a single component alone on a canvas, styled entirely by named tokens (accent.base, corner.radius, control.density, font.body, theme.mode), with those tokens emitted as a machine-readable manifest an agent can consume. Same loop, .NET-native:

Pros

• AI tools can finally target Blazor by default — scaffolding and porting shadcn/React apps onto Fluent 2.
• Ownership answers the theming/customization asks that keep surfacing — e.g. #1049 "How to simplify theme management?", one of the most-upvoted discussions in the repo. If the styleable layer is source you own, "I can't get the exact look I want" stops being a wall.
• Deliberate updates. --diff-style drift detection means teams pull improvements on their schedule instead of fearing a NuGet bump.
• Reuses proven prior art. The registry schema, CLI UX, and MCP integration already exist and are battle-tested (OpenAI, Adobe, Sonos ship on it). You'd be adopting a standard, not inventing one.
• Strategic moat for Microsoft, not just nicer DX.

Cons / open questions (the honest part)

• Shadow DOM is the real obstacle. Today's Fluent Blazor components are wrappers over FAST/Fluent web components, and much of the styling lives locked inside shadow DOM + the adaptive color system. shadcn works precisely because the styleable surface is open source (React + Tailwind classes) the dev and the model can edit. A registry over opaque wrappers gives ownership of the wrapper but not the look. This is the crux: how much of the styleable surface can realistically be made open/editable vs. staying locked in the web-component layer? Maybe the registry ships the Razor + token bindings + optional CSS-part overrides, and a subset of "open" components go further. Worth an honest scoping conversation.
• Consistency-vs-ownership philosophy. This library has historically (and defensibly) chosen consistency and adaptive-accessibility over flexibility. The shadcn model deliberately trades maintained-for-you safety for owned-by-you control. That's a real values question, not just an engineering one.
• Maintenance surface. A registry, a CLI, a token pipeline, and an MCP server are ongoing commitments, not a one-time PR.
• Tooling home. NuGet isn't a natural "copy files into my repo" mechanism; a dotnet tool or an npm CLI fits better. Which one serves the goal — .NET-native ergonomics, or maximum reach into the AI-tool ecosystem that already speaks npm/shadcn?
• Fidelity of the port. A shadcn→Fluent mapping will never be 1:1; the promise has to be "great starting point," not "pixel-perfect auto-migration," or it over-sells.

A possible phased path

1. Publish the token manifest (machine-readable JSON + the mapping to shadcn's token vocabulary). Low risk, immediately useful to agents.
2. Ship an experimental registry + CLI for a small set of "open" components to prove the copy-local + --diff loop in .NET.
3. Add the MCP server exposing catalog + tokens + mapping.
4. Publish the React/shadcn → Fluent Blazor porting skill as the headline capability.

Questions for the maintainers

• Is opening up the styleable surface (beyond tokens) even compatible with the FAST/shadow-DOM architecture, or would this require a parallel "open components" track?
• dotnet global tool, NuGet, or npm-based CLI — which best serves both .NET devs and the AI-tool ecosystem?
• Is "make Fluent the default AI target" a goal you'd actively want to pursue, or a non-goal for this library's scope?

[vnbaaij]

Hi,

First of all, thanks for your extensive proposal. There is a lot to unpack here!

Before answering your 'questions for the maintainers', I want to repeat (or clarify maybe) what the status of this project is:

We are a fully open-source, non-funded, project that lives in the microsoft organization here on GitHub. There is no official team inside .NET or ASP.NET Core that owns this, funds this, or gives direction to what is built (or how). This originally started as a project owned by the FAST team (who built the Fluent UI Web Components) to demonstrate how integrate and use the components from a bunch of frameworks. I got involved as an employee when I was already a BlazorFluentUI admin and heard that this project was stated internally. I continued to work on this as a side-project, was joined by Denis in maintaining this as (nowadays) a group of enthusiastic (former) employees that just love to work on this and .

It seems that to do what you propose, goes (well) beyond what we as maintainers have a say about.

Your proposal and questions:

I think what you propose (please correct me if I'm wrong) is to offer a way for developers to get component source code 'injected' into their own project/code.

That is a whole (radically) different approach than what we know in the .NET and Blazor world currently where you just consume what is provided to you through a NuGet package. Yes, that may offer less customization, but on the other hand, it also protects the dev from missing to add auxiliary, required code (like a base class or service collection extensions, etc).

Building in support for something in a successful way like that would require, I think, involvement form the .NET/ASP.NET Core/Blazor teams

• Is opening up the styleable surface (beyond tokens) even compatible with the FAST/shadow-DOM architecture, or would this require a parallel "open components" track?

• dotnet global tool, NuGet, or npm-based CLI — which best serves both .NET devs and the AI-tool ecosystem?

You probably need all 3 of them. Global tool for the dev's local environment, NuGet to get the basic, shared, library components in place and a CLI (not sure if it must be npm based) to help use the things from the AI part of this.

• Is "make Fluent the default AI target" a goal you'd actively want to pursue, or a non-goal for this library's scope?

I think this is a non-goal for the library at this moment because

1. We lack the knowledge and resources to pull this off
2. We can't speak for the broader Microsoft Blazor part of things (referring to your 'Why this is a Microsoft-shaped opportunity' part)
3. We already have developed a MCP server that greatly improves working with the library from an AI perspective. I'm not sure if want/need to invest more into that in the short term.

[buvinghausen]

This is a genuinely generous reply, especially knowing now that it's volunteer time behind it and not a funded team.

That context reframes a lot, so let me own something up front: I calibrated the whole proposal — the "Microsoft-shaped opportunity" section most of all — to what the microsoft/ org home implied. I read institutional backing and resourcing into it that simply isn't there, and pitched something sized for an official product team with a strategic mandate. That was my mistake. It made the ask land far bigger than is fair to drop in front of a group of enthusiasts keeping this alive on the side, and I apologize for that framing.

You've characterized the core idea exactly right, too: dev-owns-the-source, "injected" into their project, shadcn-style — and yes, that's a real departure from the NuGet-consumption model .NET devs expect. Your point about auxiliary code (base classes, DI registration, and so on) is well taken. shadcn's registry does encode those as item dependencies so they travel with the component, but you're right that getting it reliably correct is real work — and doing it well in the .NET/Blazor world almost certainly needs the FAST and Blazor teams in the room, which is squarely outside what you can or should commit to.

On the three answers:

• The "probably all three" split — global tool for the local env, NuGet for the shared base library, a CLI for the AI side — is a cleaner decomposition than I had. Thank you for that.
• And I should have led with your existing MCP server. That already closes a big part of the "AI legibility" gap I was gesturing at, which makes the non-goal answer completely reasonable — less a gap to fill than something you've already started.

So: message received. I think the honest, in-scope version of this is much smaller than what I wrote — at most the machine-readable token manifest, if it's ever itch-worthy, leaning on the MCP server you already have. Zero expectation attached.

Thanks again for taking the time to engage this seriously, and for keeping the project going on passion. It shows.