Avancé

[ASP.NET MVC 6] Les nouvelles fonctions des Tag Helpers

ASP.NET logoDans ce nouveau billet, je vous propose d’aller plus loin dans la découverte des Tag Helpers ASP.NET MVC 6. Là où mon précédent billet consistait en un tour d’horizon dans la fonctionnalité, je m’attarde ici sur certains helpers qui correspondent à des ajouts de fonctionnalités, qui n’étaient pas disponibles jusqu’à présent dans des vues Razor.

Image Tag Helper

Lorsque l’on fait référence à une image dans une page web, le développeur peut vite se poser des questions quant à la gestion du cache. Le Tag Helper image est une réponse à cette problématique. Il permet d’ajouter automatiquement une Query String au chemin de l’image, la valeur de celle-ci étant calculée à partir du contenu de l’image. Si celui-ci change, une nouvelle valeur est calculée, l’URL de l’image change et donc le cache est automatiquement invalidé.

Le Tag Helper se nomme simplement asp-append-version. Il suffit de lui passer la valeur true.

L’exemple ci-dessous est un usage de ce Tag Helper.

<img src="/content/images/icon.png" asp-append-version="true" />

Le code HTML ci-dessous est alors automatiquement généré. Notez que le chemin vers l’image a été modifié et que l’attribut asp-append-version a été supprimé.

<img src="/content/images/icon.png?v=GFF5D3664423Q2fQqUk3URdgWy2ZekXjHzHJaY5yaiOOk" />

Référencement de scripts

Dans un billet que j’ai publié récemment, j’ai abordé le fait que les bundles de scripts et de fichiers CSS ne sont plus disponibles avec ASP.NET MVC 6. J’évoquais le fait que, dans un scénario de développement, il était généralement nécessaire d’inclure la totalité des fichiers scripts sans qu’ils soient regroupés. Cela correspond à l’exemple ci-dessous :

<script src="~/js/a.js"></script>
<script src="~/js/b.js"></script>

Pour éviter des erreurs (lorsque l’on oublie de référencer un script par exemple), le Tag Helper asp-src-include permet d’utiliser des wildcards dans l’inclusion des scripts.

Ainsi, je pourrais réécrire l’exemple précédent de la manière présentée ci-dessous.

<script asp-src-include="~/js/*.js"></script>

Après transformation par le Tag Helper, c’est bien les deux lignes suivantes que je peux trouver dans code source HTML de la page.

<script src="~/js/a.js"></script>
<script src="~/js/b.js"></script>

Selon le même principe, il est possible d’exprimer que certains fichiers ne doivent pas être inclus. Cela passe par l’utilisation du Tag Helper asp-src-exclude. Ainsi, je pourrais compléter la règle précédente comme ci-dessous:

<script asp-src-include="~/js/*.js" asp-src-exclude="~/js/b.js"></script>

Ce qui aura pour effet de générer la sortie ci-dessous. Notez que, même dans le cas d’une exclusion, j’aurais pu faire usage de wildcards.

<script src="~/js/a.js"></script>

Les deux Tag Helpers asp-src-include et asp-src-exclude sont taillés pour fonctionner avec l’import de fichiers scripts, c’est à dire de fichiers JavaScript. Il existe deux tags supplémentaires qui fonctionnent sur le même principe, mais qui sont dédiés à l’import de fichiers CSS : asp-href-include et asp-href-exclude.

Pour améliorer les performances d’une application Web, notamment en accélérant le rendu d’une page dans le navigateur d’un client, une pratique communément répandue consiste à utiliser un CDN. La plupart des frameworks populaires tels que JQuery ou Bootstrap propose leurs librairies sur un CDN public. Il y aura donc de fortes chances qu’un visiteur de votre site dispose déjà de la librairie en cache sur son poste. De plus, cela permet d’ôter un peu de charge réseau sur vos propres serveurs.

Malheureusement, un CDN n’est pas infaillible, il est alors nécessaire de gérer le cas où le navigateur du client n’arrive pas à récupérer un fichier depuis le CDN. Dans ce cas de figure, la solution généralement appliquée consiste à faire une seconde requête, la détection de l’échec de la première requête se faisant avec un peu de JavaScript.

Le chemin à utiliser dans cette seconde requête peut être exprimé grâce au Tag Helper asp-fallback-src. Il est à utiliser en combinaison avec le Tag Helper asp-fallback-test. Ce dernier attend comme valeur le nom de l’objet dont il doit tester l’existence. Si cet objet n’existe pas, alors il devra appeler l’URL de fallback.

<script src="//ajax.aspnetcdn.com/ajax/bootstrap/3.0.0/bootstrap.min.js"
        asp-fallback-src="~/lib/bootstrap/js/bootstrap.min.js"
        asp-fallback-test="window.jQuery">
</script>

Cet exemple produit la sortie ci-dessous dans le code source HTML de la page :

<script src="//ajax.aspnetcdn.com/ajax/bootstrap/3.0.0/bootstrap.min.js">
</script>
<script>(typeof($.fn.modal) === 'undefined'||document.write("<script src=\"\/lib\/bootstrap\/js\/bootstrap.min.js\"><\/script>"));</script>

Enfin, le Tag Helper asp-append-version dont je parlais plus tôt s’applique également aux scripts JS et permet d’ajouter automatiquement une clé calculée par rapport au contenu d’un fichier. En combinant ce Tag Helper avec l’utilisation de Gulp, que je vous ai déjà présenté, on obtient finalement une solution équivalente à ce qui était possible de faire jusqu’à présent avec les Bundles ASP.NET MVC. Le Tag Helper asp-append-version est utilisable avec les scripts mais également avec les fichiers CSS.

<script src="~/js/a.js" asp-append-version="true"></script>

Ci-dessous, le HTML généré par le Tag Helper :

<script src="~/js/a.js?v=aFdxK89NJA5vb1EsG9O9uURFDfEE3j1E3DgwL6NiDGMc"></script>

Cache Tag Helper

Ce Tag Helper est particulièrement intéressant puisqu’il ne cible pas une balise HTML existante. En l’utilisant, le développeur n’est plus dans une situation où il vient enrichir la syntaxe de HTML en utilisant des attributs additionnels et non standards, ici c’est une toute nouvelle balise qui fait son apparition. Ce genre d’ajout à la sémantique est déjà fortement utilisé par d’autres frameworks, notamment côté client, avec ce qui est fait par exemple sur AngularJS.

L’approche proposée par ce Tag Helper est particulièrement intéressante, notamment par rapport à l’attribut OutputCache que nous utilisons habituellement. En effet, là où avec l’attribut OutputCache c’est l’action qui décrit la politique de cache à utiliser, avec ce Tag Helper, c’est l’appelant qui la décrit.

Ce Tag Helper s’utilise avec la balise cache.

Il peut prendre les attributs suivants :

  • expires-after qui permet d’exprimer une valeur absolue d’expiration du cache. Le paramètre attendu est de type TimeSpan. L’exemple ci-dessous est une utilisation du cache qui doit expirer automatiquement 5 minutes après la première requête.
    <cache expires-after="@TimeSpan.FromMinutes(5)">
        @Component.Invoke("Menu")
    </cache>
    
  • expires-on qui permet d’exprimer explicitement le moment auquel le cache va expirer. L’exemple ci-dessous permet de mettre mon menu en cache pour une heure.
    <cache expires-on="@DateTime.Now.AddHour(1)">
        @Component.Invoke("Menu")
    </cache>
    
  • expires-sliding qui permet d’exprimer une durée durant laquelle le cache sera automatiquement prolongé dès lors que l’on accède à la ressource.
    <cache expires-sliding="@TimeSpan.FromMinutes(5)">
        @Component.Invoke("Menu")
    </cache>
    

Tout comme l’attribut OutputCache, le Tag Helper cache supporte la prise en charge de variations de cache en fonction de paramètres contextuels. Ces paramètres sont alors utilisés pour construire la clé de cache.

L’exemple le plus simple est celui où le cache est basé sur un paramètre passé en Query String.

<cache vary-by-query="productId">
    @Component.Invoke("Menu")
</cache>

Environment Tag Helper

Là encore, ce Tag Helper n’est pas utilisable directement sur une balise HTML standard. Il permet de conditionner le rendu d’éléments d’une vue en fonction de la valeur d’une variable d’environnement. Typiquement, cela est utile pour conditionner l’inclusion de fichiers JavaScript ou CSS en fonction d’un déploiement en production ou en environnement de recette. Il peut également être utilisé pour afficher des informations de debugage dans un environnement de recette.

Lors de sa transformation, le Tag Helper environment est automatiquement retiré de la vue. Cela signifie qu’il ne sera jamais envoyé dans la page HTML téléchargée par le navigateur internet des clients.

La variable d’environnement utilisée par le Tag Helper est la variable ASPNET_ENV. Ci-dessous un exemple d’utilisation de ce Tag Helper.

<environment names="Development">
    <script src="~/js/a.js"></script>
    <script src="~/js/b.js"></script>
</environment>
<environment names="Staging,Production">
    <script src="~/js/site.min.js"></script>
</environment>

Conclusion

Grâce à ce billet, j’espère que vous avez pu découvrir plus en détails les Tag Helpers d’ASP.NET MVC 6. Notez bien qu’il ne s’agit pas uniquement d’ajout à des tags HTML existants mais qu’il peut s’agir également de véritables nouveaux tags qui font leur apparition. Notez également que les Tag Helpers que je présente ici sont les Tags standards. Il est probable que de nombreux nouveaux tags proposés par la communauté fassent rapidement leur apparition dans les mois à venir.

Dans un prochain billet, je vous présenterai la marche à suivre pour créer vos propres Tag Helpers à partir des besoins que vous pouvez rencontrer en entreprise.

Nombre de vue : 325

AJOUTER UN COMMENTAIRE