Accueil Le blog ebiznext
Angular + Europe = ngEurope 2014 (4/4)

Dernière partie de ma série de 4 articles sur ngEurope

Jour 2 - après-midi

Be a Real Time Cage Dragon with AngularJS and Firebase

Lukas Ruebbelke nous fait la promotion du produit Firebase, un backend de stockage de données temps réel, dont l’annonce de rachat par Google arriva la veille du talk. C’est à travers un module Angular de synchronisation de données nommé AngularFire, que Lukas fait sa pub. Rien de technique, juste une petite démo avec une webapp déjà prête à l’usage.

On nous proposera d’ailleurs d’essayer nous même le service via les codes suivants :

Free Firebase account http://bit.ly/lukas-friend

code promo pour 1 mois de production : nglukas1

Lien vers le produit : https://www.firebase.com/

Lien vers le module Angular : https://www.firebase.com/docs/web/libraries/angular/index.html

Lien vers le l’appli démo : https://github.com/simpulton/falafel-manager

 

“Don’t stop thinking about tomorrow” - AngularJS and Web Components

 

Carmen Popoviciu et Pascal Precht nous proposent un talk sur l’avancement de leur travaux sur les web components. Ils reviennent pour nous sur les 4 nouvelles techno sur lesquelles ils reposent.

Un web component est tout d’abord constitué d’un template HTML, c’est à dire un bout de code html qu’on va coller dans une balise template avec un id pour l’identifier. Ce template est alors duplicable et disponible à l’envie et ses ressources (feuilles de styles, images, autres media) ne seront pas chargées tant que le composant n’est pas activé. Son activation justement s’effectue simplement par la copie du  DOM du composant quelque part dans le DOM de notre webapp.

Vient ensuite, le Shadow DOM qui permet d’encapsuler les règles CSS pour ne les appliquer qu’à la seule portée de notre composant en dupliquant et isolant une partie des noeuds du DOM général. En effet, le but est de s’assurer que les styles CSS définis dans la feuille de style embarquée par le composant ne vont pas rentrer en collision avec celles de notre site.

La 3e brique des web components est la possibilité de définir ses propres balises HTML pour donner une sémantique à nos composants. L’enregistrement d’un nouvel élément s’effectue via la fonction document.registerElement qui prend le nom de la balise à créer, un objet javascript de type HTMLElement et pour lequel on définit 2 méthodes : createdCallback qui contiendra le code à appeler pour initialiser l’état interne de notre composant ; et attributeChangedCallback qui permet de réagir à des changements de valeurs sur des attributs que notre nouvelle balise peut exposer.

Dernier point, une évolution de la balise link qui pourra prendre pour l’attribut “rel” la valeur “import” et permettre ainsi l’import de composants externes à notre page.

On nous présente ensuite l’utilisation des web components au sein d’Angular qui se fait de manière transparente. Ce dernier n’a pas une connaissance particulière des web components et les traite comme du HTML standard, et le data-binding fait très bien le boulot quand il s’agit de changer des valeurs d’attributs. Seul point encore en cours de travaux, la notification des changements, interne au composant web, vis-à-vis de l’extérieur (l’appli Angular ici). 2 pistes sont à l’étude, l’utilisation d’observer sur les attributs, et la création d’évènements lorsqu’une propriété change de valeur.

Enfin, on termine sur une possible implémentation de tout çà dans Angular 2, et l’utilisation notamment des accesseurs [] pour les propriétés, et () pour les évènements dans le markup HTML.

Ce talk était vraiment très intéressant, et on a hâte de voir arriver les web components. Il restera cependant encore quelques questions à résoudre, comme par exemple, comment surcharger le comportement d’un composant dont le code source ne nous appartient pas, ou encore la surcharge des feuilles de styles du composant qu’on ne pourra plus surcharger justement à causer de l’isolation apportée par le Shadow DOM.

 

Lien vers les slides
http://pascalprecht.github.io/dont-stop-thinking-about-tomorrow/#/

 

Lien vers le site officiel
http://webcomponents.org/

 

Lien vers Polymer, une implémentation pour les navigateurs d’aujourd’hui des web components
https://github.com/eee-c/angular-bind-polymer

 

AngularJS Accessibility

Marcy Sutton est en charge de l’accessibilité, et a travaillé de concert avec l’équipe de développement d’Angular pour nous offrir le nouveau module ngAria disponible dans la version 1.3. Sa présentation est un vrai un bol d’air frais au milieu de toutes ces conférences techniques et nous sensibilise aux problèmes de l’accès au web et à l’information pour tous, qu’on soit valide ou qu’on ait un handicap comme une déficience visuelle. Elle vulgarise pour nous les grands principes de l’accessibilité, du bon usage des balises HTML (vocabulaire sémantique), de l’utilité des attributs ARIA et comment nous sommes censés  les implémenter sur nos sites web, ainsi que les pièges à éviter.

Elle nous explique et montre comment les readers fonctionnent et décryptent pour nous un à un quelques un des attributs ARIA les plus importants, et comment nous, développeurs, devons mieux les renseigner. Elle nous indique aussi comment notre site doit être utilisable au clavier pour offrir une navigation fluide et pertinente, comment gérer les changements de focus sur les champs et autres éléments HTML interactifs et surtout ne pas oublier d’implémenter les différents changements d’état de notre application (connecté, session expirée) ou autres notifications visuelles.

C’est pour nous aider dans ces tâches que Marcy a contribué au projet Angular via le module ngAria, et poursuit son travail de facilitateur en contribuant au projet Angular Material.

Avec ce nouveau module, plus de raison de ne pas faire d’efforts pour rendre accessible nos sites et applis web à tous.

Dans ses derniers slides, elle nous propose une mine de liens pour nous aider dans cette tâche. En passant par l’url de config chrome “chrome://accessibility”, aux screen readers sur différentes plate-formes (mobile et PC), ainsi que les liens vers d’autres ressources. Je vous invite grandement à parcourir ces slides :

http://marcysutton.github.io/angular-a11y/#/

Software Patterns and Design with AngularJS

Nous sommes nombreux à nous être déjà posé la question suivante “what is the angular way to do …” mettez ce que vous voulez après. Cette question revient souvent sur StackOverflow et Jeremy Elbourn veut nous montrer qu’il ne s’agit pas de nouveaux principes inventés dans Angular mais bien des design pattern traditionnels qu’ils ont apporté dans leur framework (avec certes son vocabulaire spécifique) mais qu’on reconnaîtra pourtant assez vite.

Les services Angular sont par exemple des singletons qu’on pourra utiliser de plusieurs façons :

  • créer un cache de données applicatif

  • une façade pour abstraire les appels aux navigateurs ou à des API tierces

  • instancier d’autres objets

L’injection de dépendances permet quant à elle de faire varier l’implémentation du service, ce qui est souvent le cas quand nous faisons des tests unitaires.

Le databinding d’Angular n’est qu’une implémentation du pattern Observer avec pour objectif d’éviter un couplage fort entre vues et données.

L’utilisation de l’héritage est encouragé pour étendre des fonctionnalités existantes. Par contre étendre les contrôleurs de page est fortement déconseillé (et je confirme pour l’avoir vu pratiquer sur une application chez un client)

Enfin une liste d’anti-pattern nous est présentée :

  • Eviter les contrôleurs à rallonge

  • Eviter de mettre tout le code dans les fonctions link de vos directives

  • Utiliser des services pour stocker les états “par page” et les nettoyer à chaque changement de route

En conclusion, arrêtez de vous demander quelle est la meilleure façon de coder en Angular, mais demandez-vous si vous utilisez vous-même les bons pattern.

Lien vers les slides
https://docs.google.com/presentation/d/1eOL6ZaT-WqqC5q5D_uwE2EJxKmdWmfmXkkD4T47iYHk/edit#slide=id.g4e203762d_065

 

The power of $q

 

Dave Smith nous fait une présentation sur $q, le service qui permet de créer des promise (promesses en bon français) pour sortir du Callback Hell. Si vous utilisez Angular, alors vous devez déjà connaître cette notion et son API. Je n’ai pas bien compris du coup l’intérêt de la présentation ou alors certains développeurs Angular codent sans en avoir conscience. Cela n’enlève rien à la qualité du talk, mais bon je n’ai juste rien appris de nouveau. On pourra juste retenir qu’il existe d’autre lib permettant d’avoir des promesses comme Jquery ou Q mais que l’équipe d’Angular a préféré recréer le sien car $q est conscient du cycle de vie des objets dans Angular ($digest).

 

Liens vers les slides
http://slides.com/djsmith/the-power-of-angular-q/#/

 

Making your Angular app a maximum security prison

 

Dans cette présentation, Martin Gontonvnikas, fait avec nous le tour des techniques qui permettent de sécuriser une application et gérer l’authentification dans une application Single Page. Ce qu’il nous démontre c’est que celles couramment utilisés à l’heure actuelle ont toutes des défauts d’usage. L’utilisation d’un cookie nous rend dépendant du web framework qu’on utilise, une API n’utilise pas de cookie pour s’authentifier, et enfin un cookie n’est pas fait pour être utilisé par des tiers ou faire de la délégation de droits. Ce que Martin nous propose c’est une authentification basée sur un token, et plus particulièrement les JSON Web Tokens (jwt).

Une démo avec un site réalisé en AngularJS et un backend tournant sur NodeJS + Express permet de nous faire une idée plus précise de la solution proposée.

Je ne dirais pas que c’est la révolution du siècle car une authentification à base de token kerberos par exemple permet de faire la même chose voir plus. Cependant, cela reste une solution simple et efficace pour qui veut mettre en place quelque chose de simple et adapté dans son éco-système applicatif.

Lien vers les slides
https://speakerdeck.com/mgonto/make-your-spa-a-maximum-security-prison
Lien vers le tutorial
https://github.com/auth0/angularjs-jwt-authentication-tutorial
Liens vers les sites
https://auth0.com/
http://jwt.io
Building games with AngularJS

L’auteur de cette présentation nous montrera comment il a réussi à créer un jeu vidéo avec AngularJS.

Lien vers le github du projet https://github.com/fullstackio/ng-game

 

Tooling

Une présentation autour de l’outillage pour AngularJS. On retiendra principalement la création du module ngHint, qui va chercher à vous indiquer dans la console la cause possible de vos erreurs. Une injection manquante, une erreur de typo, etc.

On nous annonce aussi l’arrivée d’une nouvelle version du plugin Batarang.

Lien vers les slides https://docs.google.com/presentation/d/16RJPOvWMePMTkvDrugOakV9uyGFRMd3PZ3g5UofhfIY/edit?pli=1#slide=id.p
ngHint

https://github.com/angular/angular-hint

Batarang https://github.com/angular/angularjs-batarang/tree/hint

 

Questions / Réponses

La conférence se termine sur une session de Questions / Réponses avec tous les speakers de l’équipe Angular. Petit résumé :

  • Le support d’Angular 1.3 continuera entre 18 et 24 mois après la sortie de la version 2.0

  • Angular 2.0 ne supportera que les ever-green browser (navigateurs avec update auto)

  • Le nouveau routeur sera backporté dans Angular 1.3 en tant que nouveau module.

  • Pas de plan de migration prévu pour passer d’Angular 1.3 à 2.0, mais on nous conseille d’écrire notre code en ECMAScript 6 en utilisant Traceur pour se rapprocher le plus possible de la cible.

  • WebMaster Tools a annoncé que les sites web seront indexés avec le JS activé et exécuté, par conséquent le besoin de pages pré-rendues coté serveur pour répondre aux exigences du SEO n’est plus.

  • Angular continuera d’utiliser le dirty checking en lieu et place de Object.observe car les benchmarks ne viennent  contredire son utilisation qu’en de rares cas. Cependant un mécanisme pour brancher ce dernier est à l’étude.

  • Le lazy-loading  dans Angular 2.0 sera traité grâce au système d’import de module d’ECMAScript 6.

  • AngularMaterial n’est pas encore finalisé car il reste des problèmes de perf à résoudre, mais les retours utilisateurs peuvent venir modifier certaines API ou composants.

Voila j’espère que vous aurez apprécié la lecture de ces billets. Tous vos retours sur les bienvenus.