One more post I wrote this week!
I don't think there's enough appreciation for writing your infrastructure with C#!
If we could just successfully solve CI in C# we'd be really cookin 👨🍳
I mentioned a couple weeks ago that we launched our new Template Editor, and it is a Blazor WASM app (within our Blazor Static site).
I also wrote a series of posts about how it works with a ton of code samples, internal considerations and more.
It turned from one reallllllly long post into 8 shorter (but still not short) posts.
TLDR:
| Post | Description |
|---|---|
| Building a Visual Template Editor in Blazor WASM | A high-level tour of the decisions, architecture, and shared systems behind the editor. |
| Building Consistent Blazor UX with Source Generators | Turning typed C# models into consistent property controls, previews, and rendered blocks with source generators. |
| Undo, Redo, and Live Preview - No Diffs Needed | Compact property addresses, generated tracking facades, transactions, undo/redo, and preview state. |
| Why Our Blazor App Still Uses TypeScript | A practical split between Blazor-owned application state and TypeScript-owned browser behavior. |
| Beyond Text Replacement: Building Typed Template Variables | Keeping Handlebars for content while extending variables to colors, sizes, images, and other typed properties. |
| Building a System to Generate Complex CSS | Generating deterministic CSS for nested blocks, panels, previews, and both browser and server renderers. |
| Simplifying Complexity: MemoryPack to the Rescue | MemoryPack storage, read-time schema repair, and typed MagicOnion communication across browser and server. |
| Productionizing Our Blazor WebAssembly Editor | Runtime performance, trimming, loading experience, and browser-backed testing for a production Blazor WASM editor. |
Hope you like it! Would love to know what you think, if there's anything you'd like more info on - or if you think something is dumb (and why ideally).
We recently launched our new Template Editor, built from scratch in Blazor WASM.
I've been building HCTI since 2018, 99% C# and we released API-driven templates in 2020, but the feature has never gotten a ton of adoption/usage - but I'm hoping this changes that a bit.
I plan to write some blog posts soon about how this came together, the challenges, and some of the tricks used to get a really interactive-y feel.
The first iteration was really 1000% c#, but I did quickly realize a lot of the core interactive drag/drop was better suited for existing libraries in pure JS... But they function as "tools" holding no state and making all the callbacks to Blazor and relying on rendered attributes/data for their starting point.
One of the more interesting parts (IMO) is how I accomplished the undo/redo change tracking. Instead of relying on anything existing, started from scratch and without going toooo far in depth (although I'd love to) -- every block's class is mirrored to a "Tracking" model and the UI only knows how to speak to these tracking versions, which have no public setters. This enables us to have strongly typed updates/changes with a transactional log in memory (don't bother persisting it yet). Each change records its address via a packed enum/struct system to locate the specific properties, because I didn't want to deal with expressions or reflection. So it's all way way way over-engineered but super efficient (and fun to build).
The other important part for me was perf in rendering, but enabling previews/changes to happen without having to pollute the transaction log (or add overhead of reconcilliation). So for example, when you're moving your mouse around a color picker or holding down ur arrows to increment a number - the applied CSS is changing, but renders are minimized because only the specific style sheet for the specific block(s) and their properties are known to be changing. This took a lot of iterations to get right, and there's still room for improvement... But I learned a bunch of new Blazor along the way.
Finally, you may notice I'm using it as a custom element, I went this route because I wanted to constrain the WASM loading/related stuff only to the editor page(s) - and the rest of the site is Blazor Static... I couldn't find a better way? I think even the loading perf isn't terrible, but I'd definitely be curious if anyone has any thoughts?
Anyhow, I'd be very curious about any feedback, and especially if this kind of thing is interesting to the people here - because I still see a lot of "Is Blazor mainstream-able" and I'd say yes, but with a lot of asterisks... but there's not enough public products talking about implementation/use-cases?
** follow up: Just FYI, it's definitely definitely not meant for mobile.
I always wondered what the odds were of getting this combo (I’m sure someone has done the math)
But lo and behold, first roll this AM - boom!