Forem: Robodobdob

Solving Problems with HTMX - Theme Switcher

Robodobdob — Mon, 13 Apr 2026 12:19:45 +0000

Dark mode has been all the rage in dev circles for years now but not everyone is on board with it. I fall into the mostly-light-mode-but-for-that-one-app camp. No shade (pun intended) on those who chose the dark side, but it's just not for my old eyes.

However, I accept that what works for me doesn't for others and vice versa, so how do you accommodate both users in your application?

In my personal project I took it as a fun exercise to add a dark mode to my app using HTMX to do all the work. The result was surprisingly simple and, I would argue, easier than a SPA.

The Objective

This is the application in its light-mode glory.

What we want to achieve is a switch between a light and dark mode theme with a simple toggle.

Consolidate the colours

The first step is to create two root CSS files - colors-light.css and colors-dark.css and put them in the wwwroot folder as static assets.

Next, all the colours that you want to change when a theme is switched, need to be consolidated into these two CSS files as variables.

/* Dark theme colour variables */
:root {
    --app-bg: #1e1e2e;
    --app-card-bg: #2a2a3e;
    --app-surface-bg: #2a2a3e;
    --app-footer-bg: #1a3a4a;
    --app-text: #e0e0e0;
    --app-text-muted: #a0a0b0;
    --app-header-bg: #111111;
    --app-hover: 50%;
}

I found the best way to identify the colours you want is to use browser dev tools to pick the elements and then get their colour data.

Do the same for the colors-light.css file (with different colours, obviously).

Now, the existing CSS files where these colours will be used need to be updated to use the CSS variables instead of explicit colours.

.note-list-item {
    display: flex;
    gap: 0.5rem;
    align-items: center;
    justify-content: space-between;
    background-color: var(--app-card-bg);
    padding: 0.5rem 0.8rem;

    &:hover {
        background-color: var(--app-hover);
    }

    button {
        color: var(--app-text);
        padding: 0;
        text-align: start;
        flex: 1;
    }
}

This is quite elegant because it means the CSS for you application doesn't need to change, it just needs to reference a CSS variable.

The trick is to change the value of the variable.

Repeat this same process for any CSS that needs to respond to a colour change.

The final piece is to wire up the theme CSS to your wherever CSS <link..../> references are added to your application.

<link id="theme-stylesheet" rel="stylesheet" href="css/colors-@(_theme).css" />

We also need to set the default value when the page loads. I use a session variable but you could also use a cookie or some other persistence.

protected override void OnInitialized()
    {
        var themeSession = HttpContextAccessor.HttpContext?.Session.GetString("theme");
        _theme = themeSession is "dark" ? "dark" : "light";
    }

NOTE: Your server-side syntax may vary from mine (Razor), but you should be able to work out what you need

Build the switcher

Switching the theme requires a control to make the HTMX request and a server endpoint to persist the change and update the UI.

Server endpoint

We first need an endpoint that will update our session and return our updated <ThemeSwitcher/>:

// Toggle the theme session value and return the new stylesheet link for HTMX to swap in-place.
        app.MapGet("/toggle", (HttpContext httpContext) =>
        {
            var currentTheme = httpContext.Session.GetString("theme") ?? "light";
            var newTheme = currentTheme == "light" ? "dark" : "light";
            httpContext.Session.SetString("theme", newTheme);

            return new RazorComponentResult<ThemeSwitcher>(new { 
                Theme = newTheme 
            });
        });

Theme switch control

Again, use what works for you, but this is my Blazor <ThemeSwitcher/> component:

@inject IHttpContextAccessor HttpContextAccessor

<button type="button"
        class="btn btn-link"
        hx-get="/theme/toggle"
        hx-swap="outerHTML">
    @if (_isDark)
    {
        <Icon Name="sun" />
    }
    else
    {
        <Icon Name="moon" />
    }
</button>

<hx-partial hx-target="#theme-stylesheet" hx-swap="outerHTML">
    <link id="theme-stylesheet" rel="stylesheet" href=@($"css/colors-{Theme}.css") />
</hx-partial>

@code {
    [Parameter]
    public string? Theme { get; set; }

    private bool _isDark => Theme == "dark";

    protected override void OnInitialized()
    {
        // If the Theme parameter is not set (i.e., we're rendering this component for the first time), load the theme from the session
        if (Theme == null)
        {
            // Get the current theme from the session, defaulting to "light" if not set
            var themeSession = HttpContextAccessor.HttpContext?.Session.GetString("theme");
            Theme = themeSession ?? "light";
        }
    }
}

It's pretty simple in how it works. It renders a button with HTMX attributes which displays either a sun or moon icon depending on the current theme.

The current theme will default to light unless there is a theme stored in session.

The key piece that makes it work is the <hx-partial>. Because we gave our <link... /> an id attribute, we can target it with an HTMX response. In this case, the HTML fragment will be a fresh <link... /> with our updated CSS reference.

The really cool bit is the browser will detect this change and the styles are applied immediately.

Putting it all together

Now, we have our CSS themes, endpoint, and switcher component ready, we can put them together.

In my case, I just dropped it in the <footer> element:

        <footer>
            <ThemeSwitcher />
            <form method="post" action="/auth/logout" id="logout-form">
                <button type="submit" class="btn btn-link">Logout</button>
            </form>            
        </footer>

Which renders like this:

Now, let's click the switcher:

This looks cool, but you really have to see it in action:

Next steps

Of course, this just shows two colour modes, but you could have as many colour themes as you want e.g. one for colour blindness. You just need to consolidate your colours and then make them an option in your switcher.

HTMX - Rethinking the SPA

Robodobdob — Mon, 23 Mar 2026 10:41:05 +0000

About me

I have been a full-stack developer for over 25 years here in Wellington. The majority of my career has been in the .Net but I have dabbled in various backend and frontend framework in that time. I’ve worked across various industries from education, legal, government, automotive, and healthcare.

Lunit

I am currently an engineering lead in the Cancer Screening Group of Lunit. We used to be Volpara Health when I joined and then we were became part of South Korean company Lunit. We are a health technology company which provides a AI products for the screening and diagnosis of cancer.

While I am not an actual time traveler, I once heard software development described as being a time traveler…. Not only do you build for the future, you often also work
the past.

SoundsNZ

Let’s go back to the year 2003 and visit SoundsNZ.com. I worked on this site around 1999/2000 but this screenshot from archive.org is largely the same as what I worked on.

SoundsNZ was New Zealand’s first online music retailer. It was very successful at the time and they did a lot of business through it.

Architecture

Architecturally, it was a classic, server-side Active Server Pages application with a Microsoft SQL database. Because this was before “ the cloud” existed, we hosted and ran the site on an IBM server in Wellington, unceremoniously in a small room opposite the office kitchen and toilet facilities.

Classic ASP was a purely server-side Mutliple Page Application architecture which was the ONLY way to build dynamic web applications - dynamic meaning, the content rendered on screen could be different depending on various conditions or data.

Server Side Rendering

Because it was server-side, every interaction was limited to one of two things - changing the page by clicking a link or changing some data by submitting a form. This was not a limitation of the MPA architecture, but really a limitation of HTML itself.

JavaScript

Because we were a hip and modern web design company, we did use Javascript around the site for small uses of interactivity like a select-all / deselect-all for example.

But Javascript was very much a small part of the main application which was firmly entrenched in server-side rendered pages.

Enter the SPA

Then, sometime around the 2010’s we started to get a new architecture to developer web apps with. It was called the Single Page Application (SPA) and it was offered as a solution to the issues with MPAs at the time. MPAs suffered from a confluence of the prevailing internet conditions at the time, as well as patterns that could be be avoided due to browser deficiencies.

The promise

The fundamental promise of the SPA was that we could download the frontend portion of our application to the user’s web browser and let it handle the heavy-lifting of assembling and rendering our UI. This would leave the server to only be concerned with sending data to and receiving data from the frontend in the JSON format.

In a time when internet speeds weren’t great and shifting and entire DOM + assets to the browser every time the user clicked a link, just taking that hit once and then shifting lightweight JSON over the wire was a VERY attractive prospect. Not only did it reduce traffic, it made apps feel faster and more interactive because we avoided the problems of traditional server-side apps such as the dreaded white screen refresh.

Growth of the SPA

As the SPA took hold and became the de facto way web applications were built, we started to replace bespoke implementations of the SPA architecture with consistent, and dependable frameworks such as Backbone, KnockoutJS, React, Vue, Svelte, Angular + many, many, more.

Where the traditional MPA was a thin-client network
application, the SPA swung the pendulum back towards the thick-client.

Problems with SPAs

However, it wasn’t without its issues. Developers now needed to effectively manage a larger application across two machines - the server where the code ran to manage
the state and the client where the code had to manage the user.

This split personality application became worse particularly if the development team were used to a certain
server-side language or platform and then they quickly had to get good at Javascript.

They also had to now understand new things like JWT tokens and API endpoints. They had to understand REST (I will cover this specific term a bit later). And above all
else, they had to pick a framework that suited them and hope it was the right choice.

A return to SSR

Now, this all happened in the 2010-2020 timeframe. But interestingly, there’s been a noticeable shift in the web development industry back towards server-side rendering.

It is not a complete swing back, but an equilibrium is being found which balances the benefits of the MPA (server-rendering is usually must faster to render HTML) and the benefits of the SPA (an action has almost instant feedback).

In fact, some frontend frameworks now tout their server-side offerings as the START point to their frameworks. For example, I have been using Blazor since .Net 5. The Blazor Server architecture is founded very much on “the server has first shot at rendering the markup, and we’ll send the SPA bits next”. Likewise, React Server Side Components looks to be a similar pattern - send what the server rendered first (because it’s faster) and then bring the interactivity in.

HTMX has entered the chat

The pendulum swinging to the middle conveniently bring us to HTMX. I believe HTMX lies at a confluence of server-side speed / client-side interactivity / developer experience.

HTMX is founded on the fundamental question of why can’t any HTML element trigger an HTTP request or receive an HTML response. There is a more expanded version of the https://htmx.org website, but I feel this is the crux of it.

The premise of HTMX

The fundamental idea is HTMX lets the browser do what is native to it (render HTML and handle user events), lets the server do what it is good at (manage state and build HTML).

Given that HTML out of the box is actually quite limited in what it can do, HTMX seeks to introduce the missing bits of HTML that make it truly useful as the “engine of application state” aka HATEOAS. While the state is technically persisted on the server, the hypermedia is how you interact and manipulate it.

A database table can be displayed as a table in HTML.
A button in that table is clicked to remove the row which causes state to change on the server.
The database table is re-displayed with the updated state

Library, not a framework

Technically, HTMX is a library and that means there are no dependency graphs or NPM packages or node_modules to worry about. Simply add a CDN or local reference and you have HTMX-ready application.

It’s also a tiny library, so there are zero concerns about burdening your user with extra load. All the user will get in their browser is the assembled HTML and any supporting assets (HTMX, CSS, additional JS etc.).

Locality of Behaviour

Another fundamental of HTMX is the Locality of Behaviour which distills to “The behaviour of a unit of code should be as obvious as possible by looking only at that unit of code”.

In practice this means you are adding HTMX directives to your markup directly as hx-* attributes. While this may feel like it pollutes markup, it actually makes reasoning on the markup far simpler for a develop to get up to speed with.

If you look at these examples, while we can infer that getTime() is going to get the time, we don’t know how or where it will do it. We also don’t know where this actual function lives in our codebase.

<button onClick=”getTime()”>Get the time</button>

But, if we take an HTMX approach where we have a time endpoint, we can see that when clicked we are going to hit the endpoint and get a response back.

<button hx-get=”/time”>Get the time</button>

Progressive enhancement

Adding HTMX to your application does not mean you are now building an HTMX application. It will happily apply small islands of interactivity as required.

At its most basic usage, you can even just use the hx-boost attribute at a high-level in your DOM. This will give an immediate benefit by using intercepting your normal HTML interactions and then patching the DOM with the response when it comes back.

Demo code

Head over to https://github.com/robodobdob/NoteToSelfHono and clone the repo to have a play with the demo site. While I am a .Net developer, this application is actually built on the Bun/Hono stack. The README should you get started.

You will need to set up a database and storage account. You can also just browse the code and I’m sure you will be able to understand how HTMX works.

The basics

Fundamentally, pay attention to hx-* actions and hx-target attributes. They will tell where the markup in being generated and where it is ending up, respectively.

Also, look at the browser dev console and watch the network tab as your interact with the application. You will see that interactions only trigger the bare minimum of network traffic. The only things sent over the wire will be requests to HTML and responses with just the HTML you need. There are no reloads of static assets or the entire DOM tree.

Swaps

In the dev console, pay attention to the DOM elements because you see flashes of the which elements are changing from the response. HTMX patches your DOM with the response depending on the hx-target attribute.

You will sometimes notice multiple DOM elements update from a single request. This is call an out-of-band swap and these are done using the hx-partial tag. These are fragments that can be added to a response which will be stripped off by HTMX and rendered somewhere else in the DOM. This is especially useful if you have multiple updates that need to apply at the same time.

Headers

It’s worth looking at the request and response headers too. HTMX will add request headers by default which can be useful for determining aspects of the request such as which element fired it. You may want to return different HTML depending on which element as trigger, for instance. Response headers can also be used to trigger HTMX events or even plain Javascript event handlers.

Authentication

Another key benefit to HTMX is the authentication approach. With a server side model, your users can be just use cookie with. Every HTMX request is a standard browser request so it will include cookies on the request. Since the server issues the cookie, it all “just works”. No JWTs to worry about.

CSRF and XSS

A criticism levelled at HTMX is vulnerability to these attacks. All modern server frameworks have mitigations for these attacks and you should 100% be using those as if you were just doing any server side rendering.

The story so far

In my experience so far, I believe HTMX provides a best-of-both worlds to web development. You get the benefits or server-built HTML but with the fast interactivity and DOM changes that users expect from a SPA.

In defence of SSR

I think it’s also worth covering that just because something is using server-side, it is inherently slow or old-fashioned or expensive. Servers and cloud infrastructure are fast and cheap now.

Gone are the days of the multi-thousand $$$$ server in the corner of the office. We can now stand up scalable cloud infrastructure for $/month that can serve many, many users.

This belief of also based on the idea that your application is serving a public audience with a variable user base. There will be thousands upon thousands of internal web tools , that run big business globally, that will never experience the white-hot load of “Slashdotting”. They will be the tools that are built to service a specific need in that organisation and will likely have a known user base.

It is also important to consider what the application itself is actually doing. If you are building a highly interactive, realtime application like Figma, then HTMX is not for you. But, if you are buidling another forms-over-data web application like the thousands of other developers, then HTMX is likely to fit the bill.

This only scratches the surface of what HTMX is and does, so I highly recommend reading the documentation at https://htmx.org to get a sense of breadth of functionality on offer.

Quotes

In preparing this talk, I gathered various quotes from around the web about HTMX. These were all unprompted and just things I had seen in passing.

Of particular interest is the bottom quote which is from an article entitled Building Critical Infrastructure with htmx: Network Automation for the Paris 2024 Olympics. It is well worth a read because it shows that HTMX is a solid choice for large, important applications.

Useful links

Here are some other useful links which will hopefully interest you more into the world of HTMX.

https://htmx.org and https://four.htmx.org
https://hypermedia.systems
https://hyperleaflet-earthquakes.fly.dev/
https://zweiundeins.gmbh/en/methodology/spa-vs-hypermedia-real-world-performance-under-load
https://www.youtube.com/watch?v=lASLZ9TgXyc (Building the 100 year web service)
https://usvsthem.com

Finally, this a translation of a post which I found. It’s perhaps a bit extreme, but HTMX does engender strong feelings :-)

Solving Problems with HTMX - Modal Dialogs

Robodobdob — Thu, 25 Dec 2025 11:19:55 +0000

EDIT: I have retitled this post to indicate it’s actually about modals

There are many ways to implement modal popups in web development these days, but they all expect you to import a library and implement their approach.

I am a big fan of using a native approach to interaction wherever possible. It frees you from dependence of third-parties and gives you a cleaner codebase.

The Modal

Let's start with the modal element - the html dialog element. This will give us largely all the functionality that external libraries give you but with some other nice bits. For instance, pressing ESC will cancel the dialog. You also don't need to worry about z-indexes or some janky DIV that pretends to be a backdrop.

I will paste the code I am using in a current project and you can hopefully infer the necessary bits you need to know.

<dialog id="utilityModal" class="w-100 h-100 p-7" hx-target:inherited="#utilityModal_content">
    <div class="position-absolute top-0 end-0 p-2 d-flex">
        <Working Id="utilityModal_spinner"/>
        <button class="btn btn-close" type="button" command="close" commandfor="utilityModal"></button>
    </div>
    <div id="utilityModal_content" class="p-1 h-100"></div>
</dialog>

Looking at this code we can point out a few important bits.

The dialog element is the wrapper element. I also add an hx-target at to the root with the new HTMX4 :inherited modifier. This means all interactions inside the modal will be contained in the modal (unless otherwise specified).

The <button... > is used as a close button for the dialog. You will note I am also using the freshly-minted native command and commandfor APIs. These allow you to issue a set of commands to other elements without any additional JavaScript.

The utilityModal_content div is perhaps the most important part. It is an empty container which will hold the content of the modal when it is opened.

The Trigger

Now we have a modal defined, we need to launch it and put something useful into it. We can do this simply using HTMX syntax we know and love:

<button type="button" class="btn btn-light p-1" command="show-modal" commandfor="utilityModal" hx-get="/editnote" hx-target="#utilityModal_content">
    <Icon Name="plus" />
</button>

Even if you're not an HTMX dev, you should be able to work out what is going to happen here. Clicking the button will first show the modal using the native command/commandfor API. Next, HTMX will kick in and do an hx-get to the endpoint and put the response into the hx-target element. And as we know from above, that target is the content of the modal.

The end result is a DOM like this:

Before clicking:

After clicking:

NOTE: the top-layer and ::backdrop pseudo-elements are added by the browser and provide hooks for the styling shown below

Modal Utilities

Now we have a functioning, native modal with content being injected from HTMX, we could just leave it there. But you incur a few oddities that you probably want to deal with.

Issue 1

Firstly, because you are injecting markup into the DOM as your hx-target, it will remain in the DOM until you remove it, refresh the browser, or replace it with some other content.

If you leave the markup in the DOM, you can get a weird user experience where the modal opens again and it will immediately display the content from the previous open while it waits for updated content. This can be jarring to the user and even confusing. They might think something has gone wrong.

To counter this, I add a small modal utility .js file which handles some clean up on the modal content when it is closed. Yes, it's not native, but sometimes you just have to use JavaScript :-)

var dialog = document.getElementById('utilityModal');
if (dialog) {
    dialog.addEventListener('close', (e) => {
        document.getElementById('utilityModal_content').innerHTML = '';
    });
}

Again, this should be pretty self-explanatory. We register an event listed on the DOM and listen for the close event which will come from the dialog element closing (either by button click or pressing ESC). The event handler itself simply wipes the content of the utilityModal_content element so it is clean the next time it opens.

Issue 2

Now that we have the content being scrubbed on close, the second issue is, how can we close the modal programmatically in response to an event?

This is actually stunningly simple and we only need a few lines of code and HTMX will do the rest.

To start, we need our endpoint to return he right things to HTMX so it can close our modal.

app.MapDelete("/deletenote/{noteId:guid}", 
            async (Guid noteId, INotesService notesService, HttpContext httpContext) =>
                {
                    var note = await notesService.GetNoteByIdAsync(noteId);
                    await notesService.RemoveNoteAsync(note);
                    httpContext.Response.Headers.Append("HX-Trigger", "notes-updated, close-modal");
                    return Results.Ok();
                });

I am a .Net developer, so this is a C# minimal API endpoint definition, but if you have done any API development in recent years, the syntax again, should be familiar enough.

In the code snippet, I return two HX-Trigger headers. These headers will be intercepted by HTMX on the response and actioned accordingly.

All, we need to do now is wire up another listener in our utilities JavaScript and we can close (and scrub) the modal.

var dialog = document.getElementById('utilityModal');
if (dialog) {
    dialog.addEventListener('close', (e) => {
        document.getElementById('utilityModal_content').innerHTML = '';
    });

    document.body.addEventListener("close-modal", function(evt){
        dialog.close();
    })
}

Summary

That's it! You should now have the bones of a HTML modal using the native dialog element and a couple of simple event listeners. And HTMX, of course.

Bonus Styling

Because styling is not everyone's forte, here is the CSS I have used on a few projects now for this modal.

dialog {
    display: flex;
    opacity: 0;
    pointer-events: none;
    background-color: aliceblue;

    &[open] {
        display: flex;
        opacity: 1;
        pointer-events: inherit;
        flex-direction: column;
        border: none !important;
        border-radius: 12px;
        box-shadow: 0 0 rgba(0, 0, 0, 0), 0 0 rgba(0, 0, 0, 0), 0 25px 50px -12px rgba(0, 0, 0, .25);
    }

    &::backdrop {
        background: rgba(0, 0, 0, .25);
        backdrop-filter: blur(3px)
    }
}

#utilityModal_content {
    overflow-y: auto;
    overflow-x: hidden
}

Tweak it as you like, but this particular snippet will render like this:

Blazor WebAssembly with .Net Framework

Robodobdob — Thu, 23 Jan 2025 06:09:03 +0000

The Problem

You have a legacy application running on .Net Framework. It performs reasonably well despite its age, and it is
unlikely to go out of support with Microsoft anytime soon. But with .NET 8 (and now 9) well-established, there are
many improvements in code quality, security, speed and even new language features that you are restricted from using
with .NET Framework.

There are various approaches to "upgrading" a .Net Framework application. One method is the "Strangler Pattern"
whereby you carve off a piece of the legacy codebase, rewrite it, and inject it back into the application somehow.

So, how can we leverage the power of Blazor WASM to take over functionality that is current provided by old technology on .NET Framework?

Blazor WebAssembly

Fundamentally, when you run a Blazor WASM application, it is bootstrapped by a Javascript file which in turn downloads the necessary WASM binaries from the compiled application.

Since the Blazor WASM appears to the browser as like a Javascript application, we should be able to build a Blazor WASM application and then surface it inside the .NET Framework application without much trouble.

Blazor Runtime Size

A criticism often leveled at WebAssembly is the size of the download required to run the application and how it makes the app slow. While it is true the debug-mode runtime is around 20MB, the release version is closer to 7MB. It is important to remember this is a one-time download and will be cached by the browser.

It is also important to remember that many mobile apps have an initial download in the hundreds of MB, so a slight
delay while the browser downloads a runtime ONCE should be more than tolerable for most users.

The Solution

Head over to (https://github.com/two-thirty-seven/BlazorWithFramework) to get the repo code.

This repo holds a solution that spins up a .Net Framework application and embeds the Blazor application into it.

NOTE: You will need to be on a Windows machine to run the solution due to it using .Net Framework.

BlazorApp

Starting with .NET 6, Blazor introduced the idea of components being available to Javascript interop (Use Razor components in JavaScript apps and SPA frameworks | Microsoft Learn)

This exposes a new method which is the key to making this all work - RegisterForJavaScript<T>(...)

This method allows us to call into the Blazor WASM binaries and render the component out to a specified DOM node. So, if we tell the Blazor app to expose a component, we can then run some Javascript in the Framework app and put that component into the page. :-)

If you look at program.cs, you will see two components registered:

builder.RootComponents.RegisterForJavaScript<Counter>(identifier: "counter", javaScriptInitializer: "initializeComponent");
builder.RootComponents.RegisterForJavaScript<Weather>(identifier: "weather", javaScriptInitializer: "initializeComponent");

There is also a build-task in the BlazorApp.csproj file. This will take the build output from that project and copy the assets into the _framework folder in the FrameworkApp project. Yes, it is confusing, but Blazor WASM apps compile into a _framework folder for some reason.

Apart from that, the Blazor app is out-of-the-box from the template.

FrameworkApp

This project is where the magic happens. Looking at _Layout.cshtml, you will see there is a new Javascript block at the bottom:

    <script src="/_framework/blazor.webassembly.js"></script>
    <script type="text/javascript">
        window.initializeComponent = async (component, parameters) => {
            const elements = document.querySelectorAll(`[data-component="${component}"]`);
            elements.forEach(element => {
                var payload = {};
                if (element.innerText !== "") {
                    payload = JSON.parse(element.innerText);
                }
                console.log(payload);
                window.Blazor.rootComponents.add(element, component, payload);
            });
        }
    </script>

This code is actually pretty simple.

First, it will load the bootstrapping code blazor.webassembly.js that has been copied into the project from the build step above.

Next, it adds the initializeComponent callback function onto the window object and this will be called by the Blazor WASM application when each component is registered on startup.

Inside this callback, is where we wire up the components to the DOM. We do this by finding all DOM elements which have the specific data-component attribute. The value of this attribute must match the name given to the component in the RegisterForJavaScript<T>(...) call.

It will then iterate over each element that matches and will then attach the matching Blazor component to that DOM node.

The result should look something like this:

The "Counter" component is Blazor WASM but the surrounding page is straight ASP.NET Framework 4.8.

If we inspect the DOM, we can see nothing untoward, just plain markup:

Passing parameters

Rendering components is great, but what if we need to pass some parameters to the component from MVC?

First off, we can simply add a Parameter to the component in Blazor. In this example, we want to give it the API url to pull data from:

To set this value from MVC, we need to pass the properties as a JSON object to the startup script. We can do this by rendering the JSON into the DOM node and then reading it back during the initializeComponent callback (see above).

Then if you look at the code added to _Layout.cshtml below, you can see it parses that JSON string into an object and the hands it over to the component.

The final result is this if we run the Blazor app on its own and use the default sample data:

But if we embed it and pass a different URL, we get a different data result:

Developing Blazor components

You will want to develop and test your Blazor components without having to spin the .Net Framework app.

If you look at the program.cs in the BlazorApp, you will see logic which determine the run state of the project.

if (builder.HostEnvironment.IsEnvironment("Development"))
{
    builder.RootComponents.Add<App>("#app");
    builder.RootComponents.Add<HeadOutlet>("head::after");
}
else
{
    builder.RootComponents.RegisterForJavaScript<Counter>(identifier: "counter", javaScriptInitializer: "initializeComponent");
    builder.RootComponents.RegisterForJavaScript<Weather>(identifier: "weather", javaScriptInitializer: "initializeComponent");
}

If the ASPNETCORE_ENVIRONMENT launch setting is Development, it will run as a normal Blazor standalone WebAssembly project. You can then host the components in the Blazor pages and test away.

If the ASPNETCORE_ENVIRONMENT launch setting is anything else, it will register the components for JavaScript.

Summary

The ability to embed Blazor WASM components into legacy apps allows you to add modern development tooling with a relatively low friction approach.

Persisting Fluxor state in Blazor WASM

Robodobdob — Tue, 29 Aug 2023 20:49:04 +0000

If you are using Blazor WebAssembly with Fluxor, you will likely have come across the situation where refreshing the current page wipes out your state and sets it back to defaults.

This is not unique to Blazor/Fluxor - it happens in React/Redux too - but it’s a behaviour that is guaranteed to frustrate users.

This is one approach you can take to ensure that a browser refresh doesn't wipe out your Fluxor state.

Prerequisites

The following assumes you already have a Blazor WebAssembly project set up with Fluxor. If not, head over to https://github.com/mrpmorris/Fluxor and get started.

Step 1 - Session storage

First off we need to install Blazored.SessionStorage following the instructions at https://github.com/Blazored/SessionStorage. This gives us the core functionality to read and write objects to the browser’s Session Storage.

builder.Services.AddBlazoredSessionStorageAsSingleton();

Step 2 - Add a new action and reducer

At the heart of Fluxor are actions which mutate state via reducers. The beauty of actions is they can pass any object on their properties.

Normally an action would pass properties specific to a state, but this time we want an action that passes the state itself.

public record LoadUsersFromStorageAction(UsersState storedState);

Now that the action is created, we need to mutate the state in the reducer using the state object on the action.

[ReducerMethod]
        public static UsersState ReduceLoadUsersFromStorageAction(UsersState state, LoadUsersFromStorageAction action)
        {
            return state with
            {
                ErrorMessage = action.storedState.ErrorMessage,
                LoadingStatus = action.storedState.LoadingStatus,
                Users = action.storedState.Users
            };
        }

Step 3 - Add a new wrapper component

Create a new Razor component called something like FluxorSessionStorage.razor that is going to handle the reads and writes e.g.

@inject IDispatcher _dispatcher;
@inject ISyncSessionStorageService _sessionStorage;
@inject IState<UsersState> _usersState;

@ChildContent

@code {
    protected override void OnInitialized()
    {
        // read
        var savedState = _sessionStorage.GetItem<UsersState>("UsersState");
        if (savedState != null)
        {
            _dispatcher.Dispatch(new LoadUsersFromStorageAction(savedState));
        }

        // write
        _usersState.StateChanged += ((state, e) =>
        {
            var data = ((IState<UsersState>)state).Value;
            _sessionStorage.SetItem<UsersState>("UsersState", data);
        });
    }

    [Parameter] public RenderFragment? ChildContent { get; set; }
}

As you can see, the OnInitialized method is used to wire up the storage methods. These methods are only called when the component is loaded on refresh.

The component will wrap the entire Blazor app thereby capturing all the Fluxor activity.

<Fluxor.Blazor.Web.StoreInitializer />
<CascadingAuthenticationState>
    <FluxorSessionStorage>
        <Router AppAssembly="@typeof(App).Assembly">
            <Found Context="routeData">
                <RouteView RouteData="@routeData" DefaultLayout="@typeof(MainLayout)" />
                <FocusOnNavigate RouteData="@routeData" Selector="h1" />
            </Found>
            <NotFound>
                <PageTitle>Not found</PageTitle>
                <LayoutView Layout="@typeof(MainLayout)">
                    <p role="alert">Sorry, there's nothing at this address.</p>
                </LayoutView>
            </NotFound>
        </Router>
    </FluxorSessionStorage>
</CascadingAuthenticationState>

Step 4 - Test it

Now when we run the application, we should see our Fluxor state being persisted in the browser's Session Storage.

If we make any change to the state, we trigger a write to Session Storage.

Likewise, if we hit F5, we load the state from Session Storage.

Merging web.config with Azure App Configuration

Robodobdob — Wed, 30 Mar 2022 20:37:22 +0000

If you're working in the Azure space, you will probably know that Azure App Configuration is the new hotness. It allows for powerful, centralised control of the application configuration making managing local config files redundant.

However with new hotness often comes the lack of backwards compatibility. Thankfully, Microsoft haven't completely forgotten about those who still have to work with .Net Framework projects.

I won't go into how to set up Azure App Configuration with .Net Framework because it is already well documented by Microsoft.

However, what I am going to describe is a method of merging legacy config values from your web.config files with config values from Azure App Configuration into a single DI-friendly IConfiguration class.

The goodies

var builder = new Microsoft.Extensions.Configuration.ConfigurationBuilder();
builder.AddInMemoryCollection(ConfigurationManager.AppSettings.ToDictionary());
builder.AddAzureAppConfiguration(options =>
{
    options.Connect(aacConnectionString)
        .Select(KeyFilter.Any, LabelFilter.Null)
        .ConfigureRefresh(refresh =>
        {
            refresh.Register("TestApp:Sentinel", refreshAll: true)
                    .SetCacheExpiration(new TimeSpan(0, 5, 0));
        });
    _configurationRefresher = options.GetRefresher();
});

_configuration = builder.Build();

protected void Application_BeginRequest(object sender, EventArgs e)
{
    bool result = _configurationRefresher.TryRefreshAsync().GetAwaiter().GetResult();
}

This is largely boileplate code from the link provided above with the addition of

builder.AddInMemoryCollection(ConfigurationManager.AppSettings.ToDictionary())

The key here is the extension method which does the conversion

public static IDictionary<string, string> ToDictionary(this NameValueCollection collection)
{
    var dictionary = collection.Cast<string>().ToDictionary(k => k, v => collection[v]);

    return dictionary;
}

Under the hood, if you inspect the IConfiguration that the builder produces, you will see two providers - InMemoryProvider and AzureAppConfigurationProvider. Thankfully you don't need to specify which provider when retrieving the key value. They can simply be referred to by

configuration["keyname"]

NOTE: config keys that exist in both web.config and Azure App Configuration will be taken as "last wins".

Additional hotness

If you are conscious of security, you will probably not be committing secrets like connection strings to your source control. However you need these when developing code, so you store them in an gitignore'd file and reference it like so:

<appSettings file="appsettings.dev.config">

The good news is this is totally supported because the ConfigurationManager works out all this stuff before the Application_Start method is triggered.

Credit

This work was inspired by this blog post which pointed the way to .AddInMemoryCollection(...)

Azure App Configuration – Getting the connection string from appsettings.json