#fullstackfest : Barcelona 2016
Quelques jours après le Full Stack Fest qui s’est tenu à Barcelone, je tenais à partager avec vous mes impressions sur ce gros événement. J’ai assisté aux deux derniers jours de conf sur le futur du dev front.
Il est jeudi 8 septembre, près de 9 heure du matin. La fatigue des sangrias de la veille, mon ventre vide et les 25 minutes de marche me mettent de mauvaise humeur. L’idée merveilleuse d’un petit déjeuner espagnol me font marcher à toute allure vers la conférence, sachant que nous sommes déjà en retard et que le welcome speech commence dans une quinzaine de minutes. À l’arrivée on me demande quelle est ma taille de t-shirt. Je me rends compte qu’ils ont des t-shirt pour fille dans une conf tech: soulagement de 15% du taux de mon énervement. On monte les escaliers, ascenseur émotionnel, le déjeuner ne sera servi qu’à 10h50, c’est à dire après les deux premières conférences. Taux d’énervement +45%.
9h15, la conférence s’ouvre sur la vidéo d’une hackeuse/bad-girl/cool avec un piercing dans le nez. Et là, BOOM! Lumières, fumée, musique, arrivée de Bruce Lawson maître de cérémonie, un vrai show à l’américaine qui me rend impatiente d’écouter la première conf. Oublié le petit déjeuner, oublié mon manque de sommeil, ça y est je suis à fond! 16 confs pendant deux jours pourraient me faire remplir bien des pages.
Cependant je préfère vous présenter mon top trois :
Immutable User Interfaces — Lee Byron
Une bonne architecture doit être durable, répondre aux demandes d’utilisation et donner une bonne expérience à l’utilisateur.
Le couple MVC / REST est l’architecture la plus utilisée ces dernières années. Cependant, elle n’est plus vraiment adaptée à nos besoins grandissants d’applications interactives. La view et le model s’écoutent et synchronisent la data, mais on retrouve des problèmes de latence ou d’intermittence de connexion. Grâce au principe d’immutabilité, on contrôle et on définit ce qui peut changer et à quel moment. Choisir quelle view afficher grâce à l’utilisation des composants. Lee Byron nous présente donc Immutable App Architecture qui est fortement inspiré de ELM et de la programmation fonctionnel.
D’un côté on trouvera les views : React nous aide à suivre le principe d’immutabilité et permet d’écrire des fonctions pures tout en gérant le DOM mutable.
D’un autre côté on a le model, la data récupérée du serveur qui n’est composée que de getters (pas de setters ni d’événements). Mais il arrive fréquemment de devoir faire trop d’appels HTTP lorsqu’on suit l’architecture REST. Ce qui nous mène à GraphQL, un langage de requête qui nous permet de charger uniquement la data dont on a besoin. Fragments est une feature de GraphQL qui permet de définir la data à côté de la fonction de rendering, ce qui facilite la refactorisation.
Une autre problématique qu’on rencontre est lorsque l’utilisateur fait plusieurs actions en même temps. Pour résoudre ça, on crée une queue qui enregistre les actions, ainsi on garde une trace de ce qui a changé grâce à l’immutabilité.
Avec MVC et REST, on ne peut pas suivre les actions de l’utilisateur chronologiquement, ou annuler l’état et revenir à la version précédente. A l’inverse, les fonctions pures, l’immutabilité et la composition sont des pratiques qui répondent à ces problématiques.
Confident Frontend with ELM — Jack Franklin
Jack Franklin complète la présentation de Lee byron par une introduction à ELM. Il fallait s’attendre à retrouver le petit ELM dans une conf front. Jack reprend les problématiques de l’architecture MVC et de la complexité d’une data qui change sans arrêt. Il nous parle du principe d’un seul état pour retrouver une single source of truth et ainsi simplifier la construction du UI. Il faut savoir explicitement comment l’utilisateur change le state afin de pouvoir tracer ses changements dans le but d’avoir la logique et l’UI séparés (et oui, encore de l’immutabilité).
ELM est un langage compilé et typé qui préviens toutes erreurs au runtime. Dans ELM tout est immutable, et toutes les fonctions sont pures.
Une des grandes features de ELM est le MAYBE. Null et undefined n’existent pas dans ce langage, à la place on retrouve MAYBE qui permet de définir une valeur qui peut ou ne pas exister. Ce qui évite d’avoir des if et des else et des bugs. Il nous force à gérer tous les cas de valeurs, même les erreurs lors d’appels vers le serveur.
Jack nous liste ensuite les cinq étapes à suivre :
1 — Définir son model
2 — Définir ses actions
3 — Définir les fonctions d’update
4 — Définir la view
5 — Répéter
Il insiste aussi sur la courbe d’apprentissage, et sur la clarté du code. A l’inverse du javascript, plus l’application est grande, plus on comprendra les bénéfices du langage ELM.
See the data flowing through your app — André Staltz
André Staltz nous à offert un vrai show on simulant un voyage vers 2020 où coder et debugguer avec cycle.js est un jeu d’enfants. Cycle.js est un Reactive functional javascript framework . De nos jours, les méthodes utilisées pour debugguer nous permettent de comprendre le code ligne par ligne. Ces méthodes ne nous donnent qu’une partie du code à la fois et nous oblige à créer un model mental du programme. André cherche à comprendre la complexité du programme en entier lors du debug. Pour ceci, on trouve des outils de type react monocle, qui affiche la hiérarchie des composants, ou redux devtools, mais encore une fois, elles ne décrivent qu’une infime partie de l’app.
Ce besoin de visualiser la logique à haut niveau nous ramène aux reactive streams.
Afin de simplifier son explication, André Staltz nous explique le fonctionnement des streams en créant un compteur incarné par une petite histoire de légos. Et lorsqu’on ouvre la console de développement on retrouve la représentation des événements qui agissent sur le model, puis qui agis sur le DOM. De cette manière, on sait exactement à quel moment un bug bloque le flow. Je vous conseille fortement cette partie de la conférence qui dure environ dix minutes et qui vous incitera sans aucun doute à tester les streams.
Problems of todays, ideas from the future : Le thème de cette conférence nous a fait rêvé, parfois un peu trop avec des outils qui sont encore un peu loin de la réalité. Cependant, il est important d’en parler pour pouvoir créer une communauté qui mènera les projets au bout et répondra à nos problématiques de tous les jours. Comme Lee Byron l’a très bien dit, on n’aura jamais une architecture parfaite, il s’agit toujours d’un tradeoff. Développer c’est explorer et améliorer. Rien de mieux pour relancer la motivation et la curiosité d’un développeur.
Rapporté par Fhenon De Urioste
