Depuis .NET 9, on peut avec Blazor gérer sans peine les problèmes de cache de nos ressources statiques (CSS et JS). Avant cette mise à jour, je vous avais écrit un article pour faire au mieux du cache-busting (https://www.peug.net/blazor-astuce-de-cache-busting-pour-mes-fichiers-css/ ) Heureux qui peut migrer tout de suite à .NET 9 ! Voyons ça :
Qu’allons nous avoir au final ?
Au final, Blazor va modifier, comme un grand, le nom de nos fichiers statiques en leur ajoutant un petit hash qui sera une empreinte faite avec le fichier. Ce hash ne changera donc que si on modifie le fichier. Nous aurons donc :
Mise en place
Il n’y a pas grand chose à faire : Dans program.cs, on remplace app.UseStaticFiles(), qui reste compatible, par app.MapStaticAssets() . MapStaticAsset, va se charger de compresser les ressources statiques avec gzip pendant le processus de génération de l’application et de brotli pendant la publication (pour réduire d’avantage la taille de téléchargement). De plus, et c’est ce qui nous intéresse, c’est lui qui va générer les empreintes digitales (fingerprinted) de nos ressources statiques lors de la publication de l’application.
Ensuite on va simplement baliser le chemin de notre feuille de style par @Asset[] :
Concernant la compression brotli, sur mon application, par exemple que pour mes CSS j’ai un gain de 46% :
Et ensuite avec dotnet 9 :
Mais ce n’est pas tout à fait fini, regardons la suite :
Concernant les fichiers Javascript
Les fichiers JS font partie de nos ressources statiques et sont donc à gérer de la même manière, même si vous les avez placés en bas de votre balise <body>.
Cependant il y aura une petite particularité concernant les modules Javascript qui au fur et à mesure du temps seront de plus en plus répandu. Depuis ES6 (2015) il est plus commode d’écrire du code JS dans des fichiers indépendants. Chaque module peut exporter des éléments (fonctions, objets, classes, etc.) que d’autres fichiers peuvent importer selon leurs besoins. Cela favorise une meilleure organisation, limite les conflits de variables globales et facilite la maintenance du code. Et avec Blazor ils sont donc chargés qu’au moment où on en a besoin puis déchargés à la fin.
Exemple de ce petit module :
Je l’utilise donc de cette manière avec Blazor :
Le problème que nous avions avant .NET9 est que lors d’un Debug du code JS, nous devions ajouter un paramètre de version pour être certain d’exécuter le bon code : « /js/datetime.js?v1 ». Bref, ça c’était avant.
Pour le cache-busting des module JS il suffit d’ajouter dans <head> de votre app <ImportMap /> et c’est tout. C’est assez nouveau ce truc ^^ Cela va créer une carte d’importation de l’ensemble des modules JS (https://developer.mozilla.org/fr/docs/Web/HTML/Element/script/type/importmap )
Donc lors de l’exécution de votre code, le framework va se charger de référencer tous vos modules JS de votre code pour créer le script suivant qui remplacera la base précédemment ajoutée :
Remarques
- Attention, s’il vous reste des fichiers statiques avec un paramètre de version (ex : < link rel= »stylesheet » href= »@Assets[« css/datetime.css?v1« ] » ) cela ne fonctionnera pas.
- Si le chemin de votre fichier statiques est mal écrit (un slash au début) (ex : « /css/datetime.css ») cela ne fonctionnera pas.
- N’a aucun effet sur les fichiers statiques des paquets Nugets que vous utilisez ( <link href= »@Assets[« _content/Microsoft.FluentUI.AspNetCore.Components/css/reboot.css »] » rel= »stylesheet » /> : cela ne fonctionnera pas. Autant attendre que ce paquet l’implémente dans une future version
