Devons-nous réécrire les composants de l'interface utilisateur natifs ou réutiliser les composants de l'interface utilisateur JavaScript existants? Nous comparons les composants Blazor natifs aux composants JavaScript encapsulés en comprenant le fonctionnement de Blazor, y compris ce que signifient natif et interop, etc.

navigateur. Cette infrastructure d'avenir permet aux développeurs d'exploiter leur code .NET existant et leurs compétences pour créer des applications Web pouvant s'exécuter entièrement côté client sans recourir à des plug-ins de navigateur. Comme pour tout nouveau framework Web, nous avons été confrontés à une décision délicate consistant à intégrer dans le nouveau système des actifs de travaux antérieurs.

Dans le cas de Blazor, le défi se présente dans les composants d'interface utilisateur du système. modèle d'application. En raison du manque de choix antérieur, les interfaces utilisateur Web sont écrites en JavaScript, alors que Blazor utilise fortement le langage C # et la syntaxe de balisage Razor. Ce contraste saisissant force la main dans deux directions: réécrire les composants de l'interface utilisateur native ou réutiliser les composants de l'interface utilisateur JavaScript.

Explorons le défi en découvrant le fonctionnement de Blazor, ce que signifie «natif vs interop», tout en discutant des compromis. de choisir entre les deux approches.

Principes de base de l’architecture Blazor

Blazor est un nouveau type de cadre d’application Web, une première en son genre. Blazor est semblable à de nombreux égards à React ou Angular, mais ce qui le distingue, c'est que l'architecture sous-jacente est conçue sur WebAssembly au lieu de JavaScript.

WebAssembly (WASM) est un standard Web développé par le World Wide Web Consortium (W3C). , qui définit un format de code binaire semblable à un assemblage pour une exécution dans des pages Web. WebAssembly est la pierre angulaire de Blazor en ce qu'il fournit une plate-forme pour Mono Runtime for WebAssembly, un environnement d'exécution .NET compilé au format WASM.

Une application Blazor est une véritable application .NET qui s'exécute sur un environnement d'exécution .NET dans le navigateur. . C'est un facteur très important dans le processus de décision lorsqu'il s'agit d'écrire des composants d'interface utilisateur pour Blazor, car vous devez connaître le contexte dans lequel le composant est exécuté.

Blazor Architecture: DOM Abstraction

Tout comme ses frères et soeurs JavaScript, Angular et React, Blazor utilise une approche similaire pour gérer les modifications apportées au modèle d'objet de document (DOM). Quel que soit le cadre que vous choisissiez, la manipulation DOM est un processus fastidieux, souvent compliqué par une modification directe de sa structure plus souvent que nécessaire. Sans plan d'exécution approprié, la plupart des approches de manipulation du DOM détruisent et reconstruisent des morceaux de DOM, déchirant plusieurs nœuds et les repeignant. C'est un problème résolu dans les cadres modernes grâce à l'utilisation d'une abstraction du DOM.

L'abstraction du DOM dans Blazor s'appelle le RenderTree c'est une représentation allégée du DOM. Considérez l’arborescence RenderTree comme une copie dans laquelle des modifications peuvent être apportées rapidement, car les nœuds de cette arborescence peuvent être créés, mis à jour et supprimés sans conséquence du rendu de la page. Désormais, plusieurs composants du système peuvent effectuer des modifications simultanées sur le RenderTree avec beaucoup moins d'impact sur les performances. Une fois la poussière retombée, RenderTree et DOM sont réconciliés en recherchant les différences entre les deux et en ne restituant que ce qui est absolument nécessaire.

L'outil RenderTree est essentiel au comportement et à la rapidité des composants de l'interface utilisateur. C'est également un aspect important pour choisir entre la manière d'écrire les composants de l'interface utilisateur, en particulier lorsqu'il s'agit de JavaScript.

Architecture Blazor: Composants natifs

Dans une application Blazor, les composants (.razor) sont traités de manière tout à fait différent de Razor. (.cshtml) balisage. Razor dans le contexte de MVC ou de Razor Pages est traité directement au format HTML, qui est rendu côté serveur et envoyé via une requête HTTP. Une composante dans Blazor adopte une approche différente: son balisage est utilisé pour générer une classe .NET qui génère le RenderTree.

 Counter 

 Nombre actuel: @currentCount 

 Cliquez-moi 

Chaque élément HTML du composant. est transmis à RenderTreeBuilder et se voit attribuer un numéro de séquence permettant de différencier rapidement les modifications apportées au DOM.

     Classe publique Counter: ComponentBase
    {
        BuildRenderTree (constructeur RenderTreeBuilder)
        {
            base.BuildRenderTree (constructeur);
            builder.AddMarkupContent (0, "
 Counter 
  r  n  r  n");
            constructeur.OpenElement (1, "p");
            builder.AddContent (2, "Nombre actuel:");
            builder.AddContent (3, currentCount);
            constructeur.CloseElement ();
            builder.AddContent (4, " r  n  r  n");
            builder.OpenElement (5, "bouton");
            constructeur.AddAttribute (6, "classe", "btn btn-primaire");
            builder.AddAttribute (7, "onclick", M ...  (this, IncrementCount));
            builder.AddContent (8, "Cliquez sur moi");
            constructeur.CloseElement ();
        }

Cette architecture de composants est fondamentale pour le fonctionnement de Blazor et prend en charge des fonctionnalités intégrées dans le cadre, telles que: méthodes du cycle de vie des composants, modèles et validation.

Architecture de Blazor: JavaScript (Wrappers)

Un composant Blazor "natif" est celui qui est écrit en utilisant l'architecture de composant du framework, un composant qui a un RenderTree et s'accroche aux méthodes de cycle de vie. L'alternative consiste à créer un wrapper pour les composants JavaScript préexistants. Lors de l'utilisation de JavaScript, un composant est créé qui expose un ensemble de propriétés et de méthodes mappées à une implémentation JavaScript. Sur la surface, un composant basé sur JavaScript est utilisé comme composant natif, mais sous la surface, il contourne RenderTree et le code HTML est restitué en manipulant directement le DOM.

La possibilité d'effectuer des appels à JavaScript à partir d'une application Blazor est appelée l'interopérabilité de JavaScript. L'interopérabilité est une fonctionnalité nécessaire de Blazor, car elle permet de combler les lacunes entre WebAssembly et les API DOM. Ceci est particulièrement utile pour les éléments non pris en charge dans Blazor, tels que: les API de géolocalisation, d'accès au fichier et de caméra, pour en nommer quelques-unes. C'est un outil très puissant, mais il peut facilement devenir une mauvaise pratique, car il peut contourner le DOM virtuel Blazor.

Abstractions fugaces

Dans le développement logiciel, une abstraction qui fuit est une abstraction qui laisse filtrer des détails qu'elle est supposée supprimer. . Les enveloppes ont naturellement tendance à être victimes de cette définition. Étant donné que les enveloppes ont besoin d'une aide extérieure au cadre Blazor, elles nécessitent des informations supplémentaires, telles que les attributs id et ref . Le code JavaScript hérité s'appuie fortement sur id s et sur elementRef s. Comme ils existent en dehors de RenderTree, ils doivent être situés dans le DOM en traversant la structure du DOM, puis manipulés, une routine coûteuse. Si ces attributs sont obligatoires pour une bibliothèque de composants d'interface utilisateur, vous pouvez en déduire qu'il est fortement dépendant de JavaScript.

Support de contenu et de modèles

Les composants sont les blocs de construction de l'application Blazor et l'un de ses principaux actifs. Les composants peuvent héberger d'autres composants de deux manières – via des composants enfants et des modèles – et le développement de Blazor est donc très agile. Les composants enfants et les modèles sont des propriétés de composant avec une classe spéciale appelée RenderFragment un délégué qui écrit le contenu dans un RenderTreeBuilder. C'est un autre oubli pour les composants construits à partir d'encapsuleurs JavaScript et une raison primordiale de créer des composants natifs.

Les composants enfants sont extrêmement puissants car ils peuvent transformer le comportement ou la composition des composants. Une telle caractéristique peut vraiment être appréciée par exemple. Dans le code suivant, on donne à une liste TelerikTabStrip une liste d'objets Prévisions . Cette liste est ensuite répétée à l'aide d'un simple foreach permettant de créer les onglets de manière dynamique. @foreach (var f dans les prévisions)
    {
        



}

La possibilité de déclarer des composants de cette manière est due à l'architecture de composants du framework Blazor et à l'utilisation de RenderFragments.

Les composants dynamiques ne sont pas limités à de simples boucles foreach . Pratiquement toutes les méthodes C # peuvent être appliquées pour contrôler le rendu. Dans l'exemple suivant, le même composant TelerikTabStrip est utilisé avec une instruction if qui est liée à une case à cocher intégrée à l'un des onglets enfants. Changer la valeur de la case à cocher dans cette instance affecte instantanément la visibilité du premier onglet.

     @if (showFirstTab)
    {
        
            Ceci est le premier onglet.
        
    }
    
        
            
             Basculer le premier onglet
        
    

Cela est possible car la portée de showFirstTab est en dehors du composant lui-même. Étant donné que les composants sont natifs, ils respectent les capacités de rendu et de liaison de données de Blazor.

Des scénarios plus avancés apparaissent lorsque des modèles sont utilisés pour permettre la personnalisation de la manière dont un composant rend le balisage. Les modèles peuvent être utilisés pour des tâches simples telles que le formatage de valeurs ou l'affichage d'images, tandis que des modèles plus étendus peuvent transformer complètement l'interface utilisateur en ajoutant de nouvelles fonctionnalités à un composant. Pour en savoir plus sur ce sujet, l'article "Pourquoi les modèles de grille Blazor vous feront-ils tout remettre en question" donne un aperçu complet avec des exemples de code.

Pre-Rendering

Blazor n'est pas seulement capable de En cours d'exécution côté client, il peut également être hébergé côté serveur. Lorsque Blazor s'exécute côté serveur, il est capable de pré-rendre les vues pour éliminer le chargement des écrans et améliorer le référencement. La manière dont le pré-rendu fonctionne dans Blazor est similaire à la façon dont les vues et les pages ASP.NET Razor sont rendues. En fait, pour cette raison, les composants Blazor sont compatibles avec les vues et les pages ASP.NET Razor. Lors de l'utilisation de composants JavaScript, le serveur ne peut pas pré-afficher le composant, car JavaScript n'est pas encore disponible. Au lieu de cela, la page devra être rendue par JavaScript lors de son analyse par le client. Il est important de savoir que ce mode de fonctionnement n'est pas disponible lors de l'enveloppement de composants JavaScript existants.

Validation

La validation dans Blazor est étroitement liée au système de composants principal. Etant donné que Blazor utilise C # dans tout le modèle de programmation, il prend en charge la méthode DataAnnotation de définition de la validation très populaire.

 utilisant System.ComponentModel.DataAnnotations;

Classe publique ExampleModel
{
    [Required]
    [StringLength(10, ErrorMessage = "Name is too long.")]
     chaîne publique Name {get; ensemble; }
}

Le DataAnnotations peut être utilisé pour déclencher la validation dans la logique métier sur le serveur ainsi que la validation de l'interface utilisateur. Le composant intégré EditForm fournit des gestionnaires de validation et des événements qui fournissent un flux de travail transparent dans le modèle du composant.

    
    

    

     Submit 


 @functions {
    private ExampleModel exampleModel = new ExampleModel ();

    privé voil HandleValidSubmit ()
    {
        Console.WriteLine ("OnValidSubmit");
    }
}

Encore une fois, il s'agit d'un scénario qui fonctionne le mieux lorsque les composants sont construits à l'aide de composants natifs. Les composants natifs partagent un état appelé EditContext qui permet aux composants situés dans un EditForm de communiquer. Les composants natifs ayant intégré le EditContext sont automatiquement validés lorsqu'ils sont placés dans un EditForm sans code supplémentaire. Lorsque vous essayez d'emballer des composants JavaScript existants, la validation nécessite des abstractions perméables via l'utilisation des attributs Id et ElementRef .

JavaScript est-il toujours mauvais?

Il n'y a absolument aucun problème avec l'utilisation Bibliothèques JavaScript pour prendre en charge des composants Blazor. Il existe certains cas où JavaScript interop est une nécessité pour combler les lacunes, car WebAssembly et Blazor sont des produits en pleine maturation. L'interopérabilité de JavaScript peut être avantageuse si elle est utilisée pour augmenter les composants natifs en ajoutant des fonctionnalités qui ne perturbent pas RenderTree telles que la focalisation ou la navigation au clavier. En outre, les bibliothèques JavaScript peuvent être utilisées pour ajouter des fonctionnalités au niveau du système lors de l’exploitation d’API Web DOM telles que GéoLocation, Accès aux fichiers, Canvas et SVG.

Telerik est l’automate

avec . ] Interface utilisateur Telerik pour Blazor nous avons adopté une approche de développement le premier à l’origine, pour la création de composants d’interface utilisateur. Notre meilleure pratique consiste à mener l'implémentation native autant que le cadre le permet, en tirant parti de RenderTree et en permettant aux composants de s'intégrer naturellement aux modèles et à la validation. Nos composants utilisent très peu le JavaScript, ce qui évite les infiltrations filtrantes qui filtrent à la surface et ne gênent pas le client. Nous avons constaté de nombreux avantages avec les modèles offrant une approche ouverte aux applications de création Web.

Notre marque Kendo UI de composants JavaScript est un atout considérable pour nous et nos clients. Cependant, nous avons déterminé que La meilleure approche consiste à reconstruire pour Blazor avec les connaissances acquises lors de la création de composants d'interface utilisateur pour Kendo UI. Nous pouvons ensuite l'appliquer à Blazor à l'aide de ses technologies entièrement natives, plutôt que d'envelopper le travail JavaScript et de le transmettre aux clients comme quelque chose de nouveau.