Meetup : RX Blazor / .NET 5

Transcript

2. RX : Blazor WASM 9 Mois après ! présente Jérôme GIACOMINI
3. Agenda Qui sommes nous ? RX : 9 mois de Blazor WASM Nouveautés .NET 5
4. Qui sommes nous ?
5. Jérôme • Avant Ketchapp : • 13 ans d’XP dans l'écosystème .NET • Chez Ketchapp : Technical Director • Mon rôle: • Gérer les équipes techniques • Créer et maintenir les outils pour les divisions de Ketchapp ! • Rattraper et dépasser le gap technologique que nous avons avec certains de nos concurrents
6. Jonathan Depuis 4 ans dans le JV Gameplay Programmer dans la VR Publishing Coordinator chez Ketchapp Mon rôle : Développeur SDK (Unity) et Full Stack
7. Ketchapp Ketchapp est Publisher de jeux vidéos mobiles Nous avons plus de 200 jeux dans notre catalogue 2 métiers : Publier et marketer des jeux vidéos hypercasual Nous collaborons avec plus de 60 studios Créer des jeux vidéos Nous faisons partie de la grande famille Ubisoft En quelques mots
8. Recrutement
9. RX : 9 mois de Blazor WASM
10. L’existant Le CHAOS : Chaque développeur choisissait sa technologie côté back office et front office VueJS NodeJS PHP JQuery Python ... OS des dévs : 1/2 sur macOSX 1/2 sur Windows
11. Notre choix Ne pas réutiliser les anciens BO Garder les SDK natifs / Unity Faire converger toute l’équipe vers une seule compétence C# : Unity (SDK) + code natif ASP.NET Core en Backend Blazor Frontend Avantage : Un dév SDK peut aussi màj le BackOffice ou les API
12. Quelques chiffres 2 Back offices créé 70/ 80 pages 155K lignes (Front et Back End / API) 6 dév sur les projets
13. Demo
14. Les + Garder une stack entière en C# : Pas de JS, pas de typescript (donc pas de système de build pour le front !) Réutilisation de ses skills C# côté client Possibilité de réutiliser toutes les libs .NET Standart Système de component simple à comprendre
15. Les + Communication avec le backend simple : Partage de DTO entre client et serveur Partage de code de validateurs On partage les même exception côté serveur et client Quand un service côté API lance une exception, on l’a remap côté client ! Evite un grand nombre de bugs ! Injection de service : très proche d’ASP.NET Core
16. Les + Une communauté très active : Awesome-blazor : un grand nombre de library ready to use Les lib payantes prête D1 : A la sortie de Blazor : Telerik / SyncFusion était déjà prêt
17. Les - Pas d’hot reload Pas une aussi grande richesse que librairies que JS Le débogage sous mac VS 4 mac : bien inférieur à VS 4 Windows Ne fonctionne pas avec les navigateur préhistoriques
18. Les pièges a éviter Mixer page MVC + Blazor L’authentification géré par ASP.NET Core = CHAOS La SPA + le site web ne cohabite pas très bien
19. Quelques limitations ! Nous ne pouvons pas changer dynamiquement: La balise title dans l’entête de la page ! Les feuilles de style chargés
20. Ma lib à moi Elle me parle d’aventure! Blazored.Toast : Toast THEM ALL Markdig : lib .NET Standard pour gérer le markdown BlazorPro.BlazorSize : permet de créer des composants « responsive » Blazored.LocalStorage : accès au LocalStorage (déprécié en .NET 5) Telerik : nous sommes entrain de le supprimer de notre site !
21. Nouveautés .NET 5
22. CSS isolation Possibilité de créer des fichiers CSS au nom du component [COMPONENT].razor.css A la build le css est ajouté automatiquement au site ! Génère des noms de classes unique dans le projet ! Cela va simplifier l’écriture de nos css
23. dotnet watch Désormais lorsque l’on lance l’app Blazor avec la commande : dotnet watch run Si on update un css ou du HTML le site se relance automatiquement plus besoin de le faire manuellement Ce n’est pas encore le « hot reload », celui est prévu avec .NET 6
24. HTML head Deux nouveaux tags : Title Link
25. Protected browser storage Nouvelles API :
26. UA Virtualization Avant : Après :