Sending messages between Blazor components is very simple, and can be very useful. If you’re used to messages in MVVM, and want to know how to do this in Blazor, read on…
As I have mentioned a couple of times, I’ve been creating some reusable Blazor components, to save time on future development. This (rather long) blog post details my journey from innocent newbie to GitHub ninja. Well, maybe not quite that far, but I learnt how to use GitHub actions to build and deploy Nuget packages, and deploy an ASP.NET web site via FTP.
I previously blogged about creating a busy indicator in Blazor. That works fine, but there is more we can do. As my loyal reader knows, I have been trying to make my code more functional for some time, and have been using the rather fabulous LanguageExt nuget package to help. One of the most basic, but extremely useful parts of this package is the `Option` monad (oh no, the m-word!). This allows you to handle the case where the data you want doesn’t exist, without having to allow those naughty null references creep in your code. I was wondering how we could handle this in Blazor. GitHub user orthoxerox suggested creating a Blazor component with two render fragments, one for the `Some` case and one for the `None` case. This was simple, but very effective. Whilst playing with this, it occurred to me that we could extend it to combine…
I’ve been working on a new Blazor project for a few weeks, and have been bothered by the number of seemingly odd errors reported in the Visual Studio error panel. The main reason they bothered me (other than the unhelpful fact that they all claim to be on line 1 character 1 of the relevant file, which isn’t very helpful) is that the code runs fine. Whilst this has been annoying me, as things were working, I didn’t spend too much time on it.
However, I just ran into another problem, and the solution turned out to solve this one as well.
My frustration at not being able to find some Blazor project templates in Visual Studio, and how I discovered the dumb stupid reason why.