Recently I got a comment on my first Blazor and WordPress blog post that my demo wasn’t working. I hadn’t looked at it in months, but sure enough my weather forecast component wasn’t rendering. Blazor was working, but it was defaulting to ‘route not found’ condition.

I have learned a bit more since my original experiment, so I dug back into my demo and made some improvements.

In my first version, I used the router, and set my @page directive to match the url of the blog post.

For some reason the router was no longer recognizing that route. I assume some wordpress upgrade messed with the url rewriter, but I didn’t look into that closely – I decided that was the wrong approach. Instead, I just updated the router (my app.razor file) to rely on the notfound condition:

Now my app has no routes defined, and I rely on my defaultlayout.razor page to always render. Note that I can likely get rid of the <Found condition in the router – I didnt only because it was working and I didn’t want to mess with it anymore.

So my DefaultLayout.Razor file is pretty simple:

All it essentially does is render my weather forecast component. I think this is a much better pattern to use when embedding Blazor in WordPress. If you do need to deal with routing, my recommendation would be to either sniff the url in your blazor app and decide what to do, or just control the state of your components by setting variables that cause components to either show or hide.

A couple other thoughts:

• You may have to add mime types to your WordPress server if your app doesn’t work or you get console errors. Take a look at the web.config that gets generated when you publish, and you will see the ones you need.  If you manage the wordpress hosting server you can add them in on your admin panel.  If not, there are some wordpress plugins that allow you to manage mimetypes.
• I am beginning to wonder if embedding blazor in wordpress is the right architecture.  The other option is build a blazor app that calls the wordpress API – and just have it pull all the wordpress content into your standalone blazor app.  That way you can still maintain the content in wordpress, but you have the full flexibility of blazor routing. If you don’t change your themes a lot, and you don’t require a lot of plugins, this approach might be better.  Just a thought.  SEO would be an issue in this approach though, since search engines don’t appear to index Blazor apps.

For reference, below is the working example of the Blazor rendered weather forecast:

Loading…

I am surprised there is not more chatter on the internet about integrating WordPress and Blazor – its a pretty interesting solution to quickly adding components to a WordPress site. If you follow the instructions from my previous post, along with the things I learned above, you can easily get it set up.

I have been building out my first Blazor application, and have been figuring out the pattern I want to follow for user authentication. Rather than use the built in Blazor authentication components, I am using the libraries I have built over the years, and I can plug into almost any app without having to think.

Where I got tripped up a bit with Blazor was in communicating the logged in an logged out status across components. After lots of Googling and experimenting, here is what I came up with:

In my Blazor Mainlayout page, I embedded the login bar component directly. This login bar just shows a login button, or if the user is logged in shows a logout button and the users name. When the signin button is clicked, the logon bar launches a login form component to collect username and password, and call the authentication API with the credentials. When a login is successful, the login bar updates a singleton class applicationvars.cs that holds all the profile information. This singleton allows all pages in the application to access these values. This is a nice, compact, and elegant way to handle what we used to call global and session variables – and is rapidly becoming one of my favorite things about Blazor.

Where I got tripped up was when I wanted to enforce a logout, or deal with a user session expired situation and message it appropriately. I finally settled on the solution of adding multiple routes to the same index page. I built route called ‘/logout’ and ‘/expired’, and added that route to the index page:

Where I erred was I put the logic to destroy the credentials in applicationvars inside the index page, which renders after the login bar, so the login bar didn’t reflect the credentials change. I futzed around with trying to get the index page to fire an event when the logout is detected, and have the login bar listen for the event and update appropriately. The better solution was to have the loginbar sniff the url, and when it sees the logout or expired URL, it destroys the credentials and redirects to the appropriate index URL. It was a much more elegant solution than getting the event wired up. It makes me wonder – maybe a new rule I need to follow: for your average business application, if you have to fire an event, you are probably doing something wrong in your design.

This design is working, and so far it has nicely isolated the authentication logic from the rest of the application. One worry is there is no easy way to have the app communicate with the login bar, so I may have isolated it too much. In recent various Blazor blog posts, I have noticed people are moving away from the singleton approach in favor of wrapping application vars around the whole application in the router. This new technique doesn’t change the over concept, so I may adapt that pattern in my next project. But for now, I will proceed with this pattern, and see how many times this paints me into a corner I don’t want to be in.

I have been reading a lot of bad reviews about Microsoft’s new dual screen device called the Surface Duo. What I find most surprising is most the bad reviews center around the lack of purpose for a dual screen device. The Windows Blog provides a pretty good overview of the device.

It seems to me there would be demand for a dual screen device – no so much for single app use, but for business multitasking. It seems to me the logical use case is to have one side of the phone for apps consuming media, the other side for apps where your create media. So if I was to get one, I would likely keep my email and messaging app on one side, and my web browser and reading apps on the other. Other use cases Microsoft shows that essentially using the device as a doublewide screen are less compelling to me, as even a double wide screen is probably too small to do any real work. But for a productivity tool, I think this form factor will catch on.

Besides the consternation regarding how to use the device, the bad reviews have focused around the low specs on this device. On this point I agree – for a list price of $1,400, I would want a more high end device.

The low end specifications for such a high priced device will put this product at a disadvantage, and it may not succeed. But I don’t necessarily think Microsoft was planning on a huge success in this round. This is an experiment and I think they are looking to see what users and app developers do with this form factor. Again, at $1400 this device isn’t for me, but I give Microsoft credit for putting it out there.

In the past few months I have become more curious about the air quality of our house.  I noticed as I get older I feel more congested in the winter, and lately our cat has been sneezing more – so I decided to throw technology at the question.  In the winter here in the Pacific Northwest, we keep the windows closed most days in winters, and we don’t usually have all the rooms in our house fully heated.  In winter months, when I am not heating my office it can dip down to the low 60’s, and with the wet weather we receive, I wonder if we have mildew or other organisms that like damp, cool environments. 

So I decided to research air quality trackers, and came across this Awair Air Quality monitor.

I was able to buy it at just over $100, and while it was more than I wanted to spend, but I couldn’t pass up the connected home features this one offers.  It comes with a nice app that gives you more than enough information about your home air quality.  I set it up in my office where it sits on my desk and I can see the numbers go up and down.  I have it set up to give me notifications on my phone when thresholds exceed certain levels.  After watching it for several months, the only thing it gives me a low score is typically on is the temperature and humidity.  If I don’t have the heat on in my office, the humidity can quickly rise to above 70% on rainy days, which isn’t great.  So I have been using this monitor to manage the humidity without grossly heating an empty room.

This does detect chemicals in the air pretty well though. One weekend, I got an alert from my Awair that chemicals in the air were high. I was just sitting in my office, and the numbers were spiking out of nowhere. After thinking about all the stuff I had been doing that day, I realized what was probably causing the issue. Earlier in the day around 2pm, I had painted a closet door in the garage with latex paint, and after I was done I used a utility sink to wash out the brush I was using. I have done this for years, never thinking anything of it. Well it turns out, the furnace is in the same room as the sink, and when the heat kicked on, it must have picked up all the latex compounds that I washed in the sink.

Note that from the above data the number spike corresponds to a heat increase around 4:30pm – when the furnace kicked on. Amazingly just washing paintbrushes was enough to hit an unhealthy level in the house.  Since then, the numbers have gone back down to normal and have not spiked since. I have some more painting to do – so I will test this out again just to prove my theory.  

I tried moving the Awair to the Kitchen, and it seems pretty accurate detecting smoke from cooking too. Pretty much anytime when cooking, the particulate numbers will elevate, and turning on the kitchen fan does affect the numbers. Interesting the quickest way to get the numbers down is to open doors and windows, which almost immediately flushes the air.

For just over $100, this Awair appliance is interesting, although once you measure your air for a period of time, it doesn’t give you much actionable info.  And I am not sure it answers my question about the mildew or mold in the air, but it does tell me I have no major problems.   For now though, my indoor air quality is for the most part excellent and so I can rest (and breath) easy.

If historians ever write about software development in the 2010’s, the main discussion point will have to be the mess caused by JavaScript and competing JavaScript frameworks. The chart from Google trends shows how each year a different JavaScript framework was the ‘best framework to use’:

The reason this happened is they are all inferior. A JavaScript framework itself is a tool to try to cover up the deficiencies of JavaScript, a language that had developers grasping for a tool that would help. With frameworks came helper packages to help deploy frameworks, leading to a huge conglomeration of various packages needed to write front end software to run in a web browser.

The legacy of this mess will be with us for years. React is currently the winning framework (if you use Google search trends as a guide), and so new applications will more likely be written in React than the other frameworks. Thus, the pool of experienced developers with these older frameworks will shrink, making it more difficult to maintain these applications written just a few years ago. And no developer will want to put Vue or AngularJS on their resume when React is what is in demand at the moment, further weakening support for the older frameworks.

Granted many developers who know one framework know others, but the pressure will be one to translate, or rewrite an application from one framework to another. And that effort is expensive. Given that the business rules have likely changed since the original app was written in the mid 2010’s – it’s likely a new app in the current framework will be written from scratch. The good news I guess is since these apps only had a useful life of say 5 years, they will be easier to rewrite – but it won’t make the business person paying the bill feel any better.

Here is where I bring up Blazor – my favorite development tool of the day. While everybody is still writing apps using React – I think Blazor will be the ultimate winner. Its a much simpler, elegant, and efficient front end than any JavaScript framework can build. Remember – JavaScript frameworks are built on JavaScript, an un-typed, interpreted language. Blazor is a binary in WebAssembly using C#, allowing full stack developers to work in the same language from the front end to the server.

It’s still early days for Blazor, as the chart above shows. But I am confident that Blazor will be the winner, and I am currently writing all new apps using Blazor. Unfortunately for the business world, I expect in a few years I will be fielding lots of requests to rewrite very young React applications in Blazor.

APPIP ERROR: amazon-search[

]