Working on my GitHubDashboard Blazor application I soon realized that I need to interact in one way or another with the browser’s local storage. If you missed my previous posts, the main idea of this application is to be “as single page as possible” even if running on the server side hosting model and therefore I chose to go for an Angular inspired architecture. Long story short, I needed a way to persist the token I receive from GitHub so that user’s don’t need to login again if they refresh the page. And, of course I didn’t want to “talk” to the server to achieve this. The natural choice was to use the browser’s local storage.

There are, however, a lot of options. For most front end developers the most obvious solution would be to use Javascript. However, another one of my goals was to build this application without writing any line of Javascript by my own. I looked into the Blazor community to see if there’s any library out there that would allow we to write and read information to and from the local storage. Since the Blazor community is probably still small but very vibrant I soon found out that there are several libraries. I tried out two of them: Cloudcrate Blazor storage and Blazored Local storage. In the end Blazored is in my opinion the best suited.

Using Blazored LocalStorage

It’s very easy to use this library since the only thing you really need to do is install the NuGet package and add the BlazoredLocalStorage service to the DI container. Using this library you can easily add items to the local storage, update them, read them, clear the storage and so on. And all these features are available through both synchronous and asynchronous APIs.

Still, since my application is server hosted, things are not that easy. Why? Well because even if this is a Blazor library it still needs to rely on Javascript to write to local storage since not all browser APIs are accessible directly from Blazor. If you create a Blazor library all static assets are placed in the “content” folder of the library. The cool thing about this is that in client-side applications, Blazor knows it should look in that folder and adds references to the library’s static assets to your pages. However, this is not the case when running server-side.

Using Blazored LocalStorage in server-side Blazor apps

That’s not really a big deal. The whole concept is that in this case we need to copy the Blazored Javascript file somewhere to wwwroot and reference it in the index.html file. Then everything should work fine with some caveats.

First of all, when interacting with Javascript from Blazor mostly all tutorials and demos will place calls to Javascript function in the OnInit/OnInitAsync lifecycle methods. This assumes of course that by the time the calls are made the application is already running in the browser context. This is of course true when using the client-side hosting model, since all your DLLs will be delivered to the browser. This doesn’t apply however to the server-side hosting model where all the components are pre-rendered on the server. Therefore, when your calls need to be made, everything is still on the server, so this will generate errors.

To overcome this, one should place the Javascript calls in the OnAfterRender / OnAfterRenderAsync lifecycle methods. This ensures that by the time your app invokes the Javascript functions your component is already rendered and therefore Javascript has access to all the browser APIs.

By the way, all this applies to all scenarios where you want to invoke Javascript function, not only when you’re using the Blazored library!

Async or not?

During the training courses I deliver for people who want to learn coding every time I get to the point to speak about async and await I tell my students the following: “everytime you do something that is slower than the CPU, you should use async“. That’s why when in the server-side hosting model, I think it’s best to always use async methods where possible (Blazored included).

The same recommendation also applies for the client-side hosting model. Why? Well because local storage items are mostly stored on disk. This means that each time you read or write something from or to the local storage, this information is also written on disk. Sticking to previously described principle, writing or reading to disk is slower then the CPU so there fore async methods are highly recommended.

Working with local storage in Blazor application is made easy by the Blazored library. If you pay attention to the hosting model of your app, working with local storage should be a piece of cake and this opens a lot of opportunities to you Blazor applications. If you experienced other caveats or challenges working with local storage I would be really happy if you could drop a comment. Cheers!