Mon opinion est que WebAssembly est l'avenir d'Internet. Cette technologie est actuellement déjà intégrée dans la plupart des navigateurs modernes (ou plutôt dans leurs moteurs) sur PC et appareils mobiles. Sur des navigateurs comme Chrome, Edge, Firefox et WebKit.
Dans cet article, je vais décrire comment commencer à développer un site WebAssembly dans Visual Studio. Cet article convient à ceux qui souhaitent comprendre comment commencer à développer des applications SPA sans utiliser JavaScript, ne connaissant que la mise en page asp.net mvc, c #, html et css.
Au moment de la publication de cet article, le framework NetCore 3 est en RC1, et Blazor a la version 3.0.0-preview9.19457.4. La sortie de NetCore 3 est prévue pour septembre 2019. Quant à Blazor, sa sortie est promise plus tard en novembre 2019, très probablement après la sortie de NetCore 3.1
Table des matières:
I Installation (assurez-vous de mettre la version actuelle, après la sortie la plus probable de novembre 2019)
- Aperçu de Visual Studio - visualstudio.microsoft.com/en/vs/preview
- Modèle Blazor - devblogs.microsoft.com/aspnet/asp-net-core-and-blazor-updates-in-net-core-3-0-release-candidate-1
II Création d'un projet WebAssembly à partir d'un modèle
- Open VS preview 16.3 preview 4
- Créez un nouveau projet. Sélectionnez le modèle d'application Blazor et spécifiez le type de WebAssembly.
Le processus de création en images
III Structure de la décision
Comme vous pouvez le voir, la solution par défaut se compose de 3 projets:
- Il s'agit d'un projet client qui contient du html, des fichiers css, des images, etc. Tout ce qui sera chargé par le client (frontend). Le projet Client contient également du code pour créer le package WebAssemly.
- Le serveur de ce projet contient le code de services auquel le client accède pour obtenir des informations (backend). L'exemple implémente les informations météorologiques.
- Partagé est utilisé pour stocker des modèles de données communs pour les deux premiers projets.
IV Démarrage et débogage du blazor WebAssembly
- Définissez deux points d'arrêt. Un dans le code d'application client, le second dans le code serveur du service. Vous pouvez immédiatement remarquer que l'événement du bouton onclick appelle le code C #, pas JavaScript. Il n'y a rien d'inhabituel dans le code serveur du service.
- Exécutez la solution en mode de génération de débogage. Une fois l'assemblage réussi, le navigateur s'ouvrira et le site Web basé sur l'assemblage Web se chargera
- Essayons d'aller dans la section "Récupérer les données". Cette section contient le code faisant la demande au backend. Dès que nous essayons d'accéder à cette section, le point d'arrêt prédéfini dans le contrôleur de service fonctionne immédiatement. Le comportement est standard, rien de nouveau. Poursuivre l'exécution du code
- Passons maintenant à la section "Compteur". Voici le code implémenté qui est entièrement exécuté sur le client. En cliquant sur le bouton «cliquez sur moi», nous obtenons un résultat inattendu. Le code fonctionnera (s'ajoutant au nombre actuel 1), mais le point d'arrêt défini dans le code ne fonctionnera pas.
- Le fait est que le débogage d'une application cliente basée sur l'assemblage Web se produit dans le navigateur. Tout comme le débogage JavaScript. Pour ce faire, appuyez sur shift + alt + D dans la fenêtre avec le site en cours d'exécution. Mais il y a plusieurs conditions.
Le navigateur doit avoir une connexion directe avec Visual Studio en cours d'exécution. Pour ce faire, Chrome doit être exécuté en mode débogage avec accès à l'API du navigateur via un port spécifique.
Copiez la ligne suggérée pour lancer le navigateur. Fermez toutes les fenêtres du navigateur. Et exécutez la ligne précédemment copiée.
- Redémarrez le débogage. Si vous essayez de déboguer une application cliente ouverte dans Chrome plusieurs fois, vous recevrez un message d'erreur. Laissez un seul onglet ouvert avec le site et un seul onglet de débogage.
- Sur l'onglet de débogage, dans la structure de fichiers, vous verrez les fichiers situés sur votre disque. Où se trouve le code source. Maintenant, en allant dans le fichier "Counter.razor", nous pouvons définir un point d'arrêt dans la procédure appelée sur l'événement onclick. Lorsque vous cliquez sur le bouton "Cliquez sur moi", un point d'arrêt fonctionnera, nous aurons accès à la pile d'appels et afficherons les valeurs des variables
Tailles de fichier V et éditeur de liens
- Comme nous le voyons dans l'exemple, les tailles des données de site téléchargées sont assez petites de 2,4 Mo (après décompression sur le client de 5,4 Mo). Lorsque le site est chargé pour la première fois, les DLL requises sont chargées pour que le site fonctionne (un exemple est de savoir comment charger les bibliothèques JS), plus tard, elles ne sont pas rechargées, mais sont utilisées à partir du cache du navigateur.
- Vous devez également faire attention au fait que l'éditeur de liens est utilisé. Cela vous permet de réduire la taille des fichiers dll résultants, c'est-à-dire que les fonctions de code inutilisées sont automatiquement supprimées des fichiers.
Par exemple, System.Text.Json.dll de 288 Ko est devenu 114 Ko, et System.Memory.dll de 146 Ko est devenu 58,5 Ko. Ceci est assuré par le travail de l'éditeur de liens, ainsi que par la compression des fichiers transférés.
En outre, ce processus peut être configuré manuellement docs.microsoft.com/ru-ru/aspnet/core/host-and-deploy/blazor/configure-linker?view=aspnetcore-3.0
VI Publishing et LazyLoading, bibliothèques d'éléments
- Publiez un site basé sur un assemblage Web via les moteurs IIS ou ASP.NET Core. Plus de détails ici .
- Bien que la technologie WebAssembly elle-même vous permette de télécharger des fichiers wasm comme demandé par developers.google.com/web/updates/2018/04/loading-wasm .
Actuellement, blazor n'a pas la possibilité de charger des dll (composants wasm) en fonction des besoins d'une page particulière. Autrement dit, tous les composants seront téléchargés la première fois que vous accédez au site.
La recommandation est une - "N'utilisez pas de bibliothèques complexes pour implémenter une fonction simple que vous écrivez en trois lignes de code." Ne pas hériter de 100 + MB dll dans l'application cliente pour la possibilité d'une implémentation simple de la journalisation (réticence à écrire 5 lignes de code vous-même).
La bonne nouvelle est qu'ils promettent d'implémenter le chargement modulaire dans le noyau 3.1 - Si vous aimez utiliser des composants prêts à l'emploi pour la mise en œuvre de sites, alors des collections de sociétés bien connues comme telerik, devexpress ou par exemple le package gratuit www.matblazor.com sont déjà arrivées pour blazor
VII Conclusions
- À l'heure actuelle, la technologie peut être pleinement utilisée dans le développement de sites Web.
- Pour travailler confortablement avec blazor pour les projets Internet, LazyLoading est requis. Quelle promesse d'ajouter dans un futur proche
- Si le projet est intranet, l'utilisation de blazor dans les nouveaux développements sera la bienvenue. Il ne vaut pas la peine de discuter dans ce sens que les PC finaux sur le réseau interne peuvent être avec un accès lent, cela peut être résolu en utilisant le client RDP léger.
- ASP.NET Core 3 + blazor est l'endroit où le développeur c # devrait développer
- Je crois que cette technologie entraînera un rejet complet de javascript à l'avenir, mais c'est mon opinion personnelle.