Blazor Client

1. Première application Blazor Client

À l’instar d’une application Blazor Server, il est tout à fait possible de créer une application Blazor Client à l’aide de notre IDE de référence, ou en ligne de commande :

dotnet new blazorwasm 

L’application ainsi créée ressemble fortement à celle que nous avions précédemment, avec toutefois quelques différences. Tout d’abord, il convient de noter qu’à l’exécution, les deux versions proposent la même démonstration : une page d’accueil, un compteur et une table de données météo. La principale différence réside dans le temps de chargement initial, incompressible, car le navigateur télécharge les composants de l’application ainsi que le runtime.

Les fichiers constituant l’application sont les suivants :

Nous n’allons pas expliquer à nouveau dans le détail l’utilité de chacun de ces fichiers car, exception faite de Program.cs sur lequel nous allons revenir, ils sont tous identiques aux fichiers de la version Server (voir le chapitre Première application).

On constate par ailleurs qu’il n’y a plus de fichier Startup.cs. En effet, contrairement à la version Server, tout le code peut s’exécuter de façon statique. De ce fait, il n’y a pas ici de pipeline de requêtes à gérer. Cependant, il y a tout de même la gestion du conteneur d’injection de dépendances qui est présente. En ouvrant le fichier Program.cs, on peut y trouver le code suivant :

public class Program 
{ 
    public static async Task Main(string[] args) 
    { ...

1. Fonctionnement hors ligne

La première différence, qui est fondamentale, est qu’une application Blazor WASM n’a besoin d’un serveur que pour charger les fichiers initiaux de l’application (les fichiers de script, le runtime et la page qui contient les composants). Une fois ces derniers chargés et mis en cache, l’application peut fonctionner de façon déconnectée.

Pour illustrer ceci, nous allons lancer notre application Blazor WASM et nous servir des options de développement du navigateur pour changer l’état de la connexion (en ligne/hors ligne). Par exemple, si nous utilisons un navigateur avec une base Chromium (Google Chrome, Edge Chromium, etc.), nous pouvons trouver l’option Offline au niveau de l’onglet Network, comme le montre la capture suivante :

Mode déconnecté dans les outils de développement

Il est nécessaire de s’assurer que la case Disable cache est bien décochée pour éviter que le navigateur désactive l’utilisation du cache, ce qui aurait pour effet d’annuler le fonctionnement hors ligne. Si l’on bascule sur le mode Offline (après le chargement initial) et que l’on essaie d’utiliser l’application, on constate que celle-ci fonctionne… partiellement.

En se rendant sur le compteur par exemple, on constate qu’une erreur se produit (et non une exception, car cela n’empêche pas le compteur de fonctionner). Nous avons effectivement fait en sorte que la récupération du fichier JavaScript s’effectue de façon dynamique, mais de cette façon, le script de Blazor WASM n’est pas capable de récupérer le fichier, l’application étant déconnectée. Cela soulève un dilemme entre le fonctionnement en mode déconnecté et les performances : il est plus performant de charger le fichier JavaScript uniquement...

1. Énoncé

Faire fonctionner l’application avec Blazor WASM passe par plusieurs étapes :

2. Corrigé

L’étape initiale obligatoire est de créer le projet. Cela peut se faire à l’aide d’un IDE ou de la ligne de commande :

dotnet new blazorwasm -n BlazorWASMApp 

Le projet est créé avec les fichiers de base, que nous pouvons supprimer (le dossier Pages, le dossier Shared, le fichier App.razor et le dossier sample-data dans wwwroot).

L’application n’est plus du tout fonctionnelle, et nous allons nous atteler au déplacement des composants dans un premier temps.

dotnet new razorclasslib -n BlazorComponents