3 reasons why I've created yet another library for the downloading on Blazor apps

Introduction

A few days ago, I created a library that provides the ability to implement a download feature on Blazor apps and published it on nuget.org.

However, maybe you already know we can easily find other libraries on nuget.org that provide the same feature, and those libraries were already published a few years ago.

Then, why did I create yet another new library even though there are already the same kinds of stuff?

There are three reasons why I did it.

1. They are using "eval()"

One of the reasons is that those other libraries are using the eval() JavaScript function to load a helper JavaScript code into a web browser.

However, the strict level of JavaScript code has recently risen, so I often see the websites that prohibit using the eval() JavaScript function by the Content-Security-Policy (CSP) HTTP header.

So I'd felt I wanted to get the library that doesn't use the eval() JavaScript function.

2. They are as a service

Another reason is that those other libraries provide its feature as a "service". In this context, the "service" is the object that will be created from a DI container. So those library users have to register the type of service in that library to a DI container at the startup code inside their "Program.cs" manually.

But I felt it is boring to add those startup ceremony codes.

3. They are optimized performce

The last reason is that those other libraries include tons of codes to optimize the performance of the downloading feature to the limit using the undocumented API. Those great work and code must be deserved to prise.

But it has increased the size of the library. And I feel ordinary users and use cases don't pursue the speed of the downloading operation. And I think the default implementation of transferring a byte array for the downloading operation on .NET 6 or later is fast enough.

So I'd felt I wanted to get a simple but small package size library.

So I created a new one by myself

So I created a new one by myself.

"Toolbelt.Blazor.InvokeDownloadAsync"

https://www.nuget.org/packages/Toolbelt.Blazor.InvokeDownloadAsync

1. 100% eval() free

It uses the standard InvokeAsync("import",...) method calling to import helper JavaScript code that is written as an ES module. 100% eval() free. (Instead, it can not use for apps on .NET Core 3.x.)

2. Minimal setup

It is an extension method for the IJSRuntime interface. You can use the downloading feature immediately if there is a JavaScript runtime object. You don't need to write any code in your startup.

3. Small package size

It doesn't have massive code optimized for performance. It is simple and small content size.

Usage

Once you added the package to your Blazor app project,

dotnet add package Toolbelt.Blazor.InvokeDownloadAsync

you can use the InvokeDownloadAsync() extension method for IJSRuntime interface to start to download the contents bytes, like this:

@using Toolbelt.Blazor.Extensions
@inject IJSRuntime JSRuntime
...
@code
{
  private async Task BeginDownloadAsync()
  {
    ...
    // 👇"InvokeDownloadAsync()" ex method
    //   starts to download the contents bytes.
    await this.JSRuntime.InvokeDownloadAsync(
      "Foo.png",
      "image/png",
      pictureBytes);
  }
}

That's all. 👍

Conclusion

These are the reasons why I have created a new library, even though we are halfway through 2022.

Happy coding! :)