PlayBlazor 0.3.0

PlayBlazor

Auto-generated playgrounds for any Blazor component library. Point PlayBlazor at your components and every public [Parameter] becomes an interactive control — no story files, no hand-written wiring. Storybook asks you to write; PlayBlazor reflects.

@* One component, one line — in any docs page *@
<PlaygroundView Component="typeof(MudSelect<string>)" />

@* Or browse everything a library exposes *@
<PlaygroundExplorer Assemblies="@(new[] { typeof(MudButton).Assembly })" />

What you get

• Auto-generated controls — bool → toggle, enum → select, string → text, numbers → numeric input, RenderFragment slots → editable sample text. Defaults are captured by instantiating the component once; XML doc summaries become tooltips.
• Live Razor snippet — the code panel always shows the markup matching the current configuration (only non-default parameters, idiomatic formatting), with copy to clipboard.
• Event log — every EventCallback is intercepted and logged with timestamp and payload, so you can see OnClick and ValueChanged fire.
• Rendering environment — dark surface, RTL, checkerboard, simulated viewport widths; a PlaygroundEnvironment is cascaded to the specimen and to your theme wrapper.
• Permalinks — Share copies a URL encoding the exact configuration (?pb-MudButton=…); opening it restores the playground. Stale links degrade gracefully.
• Resilient by construction — a component that throws is contained by an error boundary; one that cannot be instantiated is reported, never fatal. Scanning all of MudBlazor is a test in this repo.

Setup

builder.Services.AddPlayBlazor(options =>
{
    // Give slots realistic content (the user's typed text always wins):
    options.For<MudButton>().Slot(nameof(MudButton.ChildContent), b => b.AddContent(0, "Click me"));

    // Templated slots (RenderFragment<T>, e.g. a table's RowTemplate) take a typed template,
    // matched to that exact generic closing; the source is what the code panel shows:
    options.For<MudTable<Person>>().Slot<Person>(nameof(MudTable<Person>.RowTemplate),
        person => builder => builder.AddContent(0, person.Name), "<MudTd>@context.Name</MudTd>");

    // Baseline parameter values (resolution: user modification > preset > component default).
    // Also makes non-drivable parameters usable — collections, expressions…
    options.For<MudDataGrid<Person>>().Parameter(nameof(MudDataGrid<Person>.Items), Person.Samples);

    // Composition graphs: components that only live inside a parent get a scaffold —
    // the played specimen is injected where it belongs, controls keep driving it.
    options.For<PropertyColumn<Person, string>>().Scaffold(specimen => builder => { /* grid around specimen */ });

    // Give a library's own icon-shaped type (no implicit string conversion, so it would
    // otherwise be undrivable) a searchable picker, by name:
    options.Catalogue(MyIconSet.Named, icon => builder => builder.AddContent(0, icon.ToMarkup()));

    // Hide providers and internals from the explorer:
    options.Exclude<MudThemeProvider>().Exclude<MudPopoverProvider>();

    // Wrap every specimen in your theme infrastructure:
    options.ThemeWrapper = context => builder => { /* your provider, driven by context.Environment */ };
});

Publishing a playground (trimming)

PlayBlazor finds components by reflection, and the IL trimmer only keeps what your code references statically. A trimmed publish — Blazor WebAssembly does this in Release by default — strips the parameterless constructors and [Parameter] properties of every component you never spell out in markup. The bench then reports "could not be instantiated" and lists the four base parameters alone, while the handful of components you happen to use directly still work, which makes it look like a per-component bug rather than a build setting.

Root the assembly you are exploring:

<ItemGroup>
  <TrimmerRootAssembly Include="MudBlazor" />
</ItemGroup>

The framework stays trimmed; only the explored library is kept whole. <PublishTrimmed>false</PublishTrimmed> is the blunter alternative.

A Debug.Assert failing inside a component lifecycle terminates the process in Debug builds; the playground converts assertion failures into error-boundary-visible exceptions by default (options.GuardDebugAsserts = false opts out; Release builds compile asserts out anyway).

The shell has zero UI dependencies — system fonts, scoped CSS, no JS beyond navigator.clipboard. It imposes nothing on the host site.

v1 limitations

• Generic components need a closed type (typeof(MudSelect<string>)); the explorer tries string then int automatically.
• Complex-typed parameters are generally not drivable from generated controls (host Parameter presets can still inject them). Two exceptions are recognized structurally and get a real control: color types (R/G/B properties + a string constructor) and icon types, the latter only when the host registers a Catalogue for it — there is no such registration for Color.
• Only the conventional ChildContent slot round-trips into the generated snippet.

Roadmap

• v2 — edit the snippet itself; parsed back into the controls (no arbitrary compilation).
• v3 — full in-browser REPL (Roslyn).

MudBlazor is the demo library this playground is pointed at, not a dependency: the package references nothing but Microsoft.AspNetCore.Components.Web.