ReactEurope 2015 : le Jardin des Merveilles ! — Partie 1
“Les bonnes idées ne veulent pas être libres, mais elles veulent se connecter, fusionner, se combiner. Elles veulent se réinventer en allant au delà des concepts.” — Steven Jonhson
ReactEurope 2015
Voilà maintenant quelques semaines que s’est achevée la 1ère édition de la ReactEurope qui restera pour moi la meilleure conférence à laquelle j’ai pu assister cette année. Léo Le Bras et moi-même vous faisions part de nos attentes dans un précédent billet (ReactEurope 2015 : J-1), et après avoir assisté à chaque talk : nous ne sommes pas déçus. Avec l’annonce officielle de la compatibilité React Native pour Android : quelle meilleure occasion pour nous de proposer quelques articles sur nos ressentis “à froid” ? Cet article sera donc décliné en 4 parties qui englobent l’écosystème React : Données, Langage, Packager & Objectifs.
Je tiens à rappeler que des interviews des speakers, ainsi que l’ensemble des talks sont à votre disposition sur la chaîne YouTube ReactEurope. Pour terminer cette introduction, à l’intention de tous ceux qui n’ont pas eu l’occasion de le faire : je vous invite à lire mon 1er article, Just React it : Acte 1, qui introduit tout ce dont je vais parler par la suite.
Talk n°1 : Christopher Chedeau, le chef d’orchestre
La toute première keynote de cette conférence, ainsi que le rôle de maestro des différents talks de cette ReactEurope 2015 étaient à la charge d’un seul et même homme : Christopher Chedeau, alias @vjeux. Pour la petite histoire, Christopher est un Software Engineer chez Facebook issu des bancs d’EPITA (cocorico!), qui travaille entre autres dans l’équipe Front-end en charge du développement de React Native !
“Je n’arrive pas à croire qu’il y a 700 personnes présentes ici, à Paris, et intéressées par React !”
- Christopher Chedeau
Écosystème React
Données
Le flux de Flux
Facebook a rendu son écosystème open source il y a 2 ans à peine, React.js étant pour la petite histoire, le 1er outil à sortir de l’oeuf. Cependant, la communauté n’avait à ce moment-là, aucune documentation, aucune guideline, rien : aucun moyen de savoir comment utiliser ce nouvel outil.
Pour mémoire, l’écosystème React est composé de la librairie React.js, du framework React Native (iOS & Android), du langage de requêtes GraphQL, du framework Relay et du pattern Flux ainsi que de la librairie éponyme.
C’est en 2014 qu’un des membres de l’équipe s’est dévoué pour la cause et a finalement documenté l’ensemble de leurs efforts. Grâce à son travail, de nombreux doutes ont été levés, ce qui a permis à la communauté de mieux cerner la volonté de Facebook avec React. Par exemple, on a pu mettre en lumière une des plus importantes particularités de Flux :
Un flux de données unidirectionnel
Flux est la réponse de Facebook au modèle MVC que la plupart de nos projets utilisent jusqu’à maintenant. Le principal avantage de Flux est de pouvoir gérer le flux des données d’applications de la taille de Facebook. Si vous avez jeté un coup d’oeil à mon précédent article, tout ceci doit vous sembler familier.
Cette doc a permis la naissance d’une pléiade de librairies qui effectuent une réimplémentation du pattern initial : Flummox, Alt, Fluxible, Marty, Redux, McFly, Barracks, Reflux, Redux, Fluxy, Fluxor,… Pour vous dire combien la liste est longue ! Gardons à l’esprit que le pattern ainsi que la libraire Flux s’inspirent eux-mêmes des librairies citées en ci-dessus. Si vous ne savez pas par laquelle commencer, je vous conseille très fortement Redux de Dan Abramov. J’évoque les traitements des données depuis tout à l’heure, mais vous me direz :
Comment récupérer ces données ?
La gestion des données
Il est apparu que le routeur joue un rôle très important ici. Comme le dit Christopher en exemple : pour se diriger vers une nouvelle route, on a besoin de récupérer les données de cette route. Ce même routeur intervient aussi au niveau du server-side rendering (rendu côté serveur). L‘une des solutions les plus intéressantes à ce problème est le duo react-router + relay. De prime abord elle peut paraître compliquée à mettre en place, manque de documentation oblige. Cependant :
“Les librairies qui font une réimplémentation de Flux permettent également de se connecter à une WebAPI et c’est souvent ce qui est utilisé quand on crée une app avec React.”
Très simplement : react router gère la navigation entre les pages de l’app. Ce dernier se base énormément sur Ember Router, dont il a extrait la substantifique moelle, pour l’intégrer à React. Il dispose d’une API simple avec des fonctionnalités puissantes que je vous invite à découvrir sur le repo de la team Rackt.
“C’est l’une des forces de React et de sa communauté : nous n’avons pas peur de récupérer des bonnes idées dans d’autres framerwoks ou librairies, pour améliorer notre écosystème !”
- Christopher Chedeau
Outre la navigation, penchons nous un peu plus sur les données qui sont après tout la base de notre application. Un autre point important de la gestion de données se résume en un terme de plus en plus courant dans notre domaine : l’immutabilité.
L’immutabilité ?
L’immuabilité décrit un principe de base de la programmation fonctionnelle, et représente un grand avantage pour les langages de programmation orientés objet. Ainsi, une valeur immuable est par définition une valeur qui ne changera pas, une fois qu’elle a été définie.
La programmation fonctionnelle est un paradigme de programmation (au même titre que la programmation procédurale ou objet). De la même manière que la programmation objet est une évolution de la programmation procédurale, la programmation fonctionnelle est une évolution de la programmation objet. Celle ci peut être utilisée en complément de ces deux paradigmes. — Pierre Barron
Pour vous faire comprendre tout l’avantage de cette approche, essayons de faire quelque chose d’apparemment très simple : comparer 2 objets en JavaScript.
var obj1 = {name: "react", state: "awesome"};
var obj2 = {name: "react", state: "awesome"};
console.log(obj1 === obj2); // falseBien qu’il n’y ait aucune erreur syntaxique, la console de debugging m’affiche une erreur : pourquoi ? Les 2 objets sont pourtant identiques, mais JavaScript ne peut tout simplement pas effectuer cette comparaison dans l’état actuel du code. Certains développeurs ont essayé d’outrepasser cet obstacle à l’aide de plusieurs raccourcis. Par exemple, avec la méthode toJSON() :
var eq = Object.toJSON(dev1) == Object.toJSON(dev2);
console.log(eq); // trueLa méthode toJSON() renvoie une chaîne représentant l’objet Date sous forme JSON. Les instances de Date identifient un instant précis dans le temps. Appeler toJSON() renvoie une chaîne de caractères formatée en JSON (en utilisant toISOString()), représentant la valeur de l’objet Date. Cette méthode est généralement utilisée, par défaut, pour sérialiser les objets Date lors d’une sérialisation au format JSON. — MDN
Cependant cette solution présente quelques inconvénients : elle n’est utile que lorsque vous avez des objets JSON simple, sans méthodes et ni noeuds dans le DOM à l’intérieur. Ensuite : l’ordre y est très (trop) important ! Le code ci-dessous retournerait une erreur avec ces 2 objets, par exemple :
x = {a: 1, b: 2};
y = {b: 2, a: 1};
var eq = Object.toJSON(dev1) === Object.toJSON(ved2);
console.log(eq); // falsePour que vous compreniez la complexité de la situation, Ebrahim Byagowi expose une solution au problème un peu plus travaillée (toujours pour effectuer cette “simple” comparaison).
“S’il on veut faire simple : comparer les objets sans aller sur les prototypes, puis comparer les projections des propriétés de manière récursive, et comparer également les constructeurs.”
- Peter Mortensen
C’est long, c’est compliqué, c’est fastidieux, c’est difficile à mettre en place et à maintenir au fil de ses projets : d’où la nécessité de l’immutabilité !
Avec le principe d’immutabilité, on peut maintenant obtenir la chose suivante :
obj1 = Immutable.fromJS({name: "react", state: "awesome")};
obj2 = Immutable.fromJS({state: "awesome", name: "react")};
console.log(obj1 == obj2); // trueLa console renvoie maintenant la bonne réponse ! Vous remarquerez au passage que même si ces 2 objets sont identiques, ils ne respectent pas le même ordre de déclaration de leurs valeurs et pourtant la librairie Immutable.js arrive parfaitement à les comparer.
Immutable.js ne s’arrête pas là et propose tout un ensemble de nouvelles possibilités pour manipuler ses données par l’intermédiaire d’une API très complète.
On a par exemple la possibilité de merger plusieurs objets :
obj1 = Immutable.fromJS({
name: "react",
state: "awesome"
});
obj2 = {
state: "fantastic",
language: "javascript"
};obj3 = obj1.merge(obj2);console.log(obj3);
// {name: "react", state: "fantastic", language:"javascript"}
Les deux objets muables et immuables ont leurs propres usages, les avantages et les inconvénients.
Les objets immuables sont donc particulièrement utiles lorsqu’ils ne disposent pas d’une identité propre, de sorte qu’ils peuvent être facilement remplacés. Ils rendent donc la programmation concurrente plus sûre et plus propre (la quête de tout bon développeur, en quelque sorte!). En effet, la plupart des bogues de concurrence difficiles à trouver sont finalement causés par des états muables partagés entre des threads.
La programmation concurrente est un paradigme de programmation tenant compte dans un programme, de l’existence de plusieurs piles sémantiques. Ces piles peuvent être appelées threads, processus ou tâches. Elles sont matérialisées en machine par une pile d’exécution et un ensemble de données privées. Les threads disposent d’une zone de mémoire partagée alors que les processus sont strictement isolés. — Wikipedia
Cependant, il existe des contextes où les objets modifiables prennent l’avantage. Dans les jeux par exemple, la vitesse est une priorité absolue : afin de représenter les évolutions de vos personnages, des objets modifiables rendront le gameplay beaucoup plus fluide que la mise en œuvre d’une solution de rechange où une nouvelle copie du personnage est générée au moindre changement.
Objets muables ou immuables, tout dépend donc de la philosophie du développeur et du résultat qu’il veut atteindre.
Le saviez-vous ?
La communauté ClojureScript a été la muse de React en ce qui concerne l’immutabilité et ses avantages (nous pouvons par exemple mettre en place des shouldComponentUpdate vraiment efficaces au sein de composant React.js).
ClojureScript est un compilateur pour le langage de programmation Clojure, qui cible JavaScript. Il est conçu pour émettre un code JavaScript qui est compatible avec le mode de compilation avancée du compilateur de Google Closure.
Les 2 domaines qui n’ont pas encore été inclus à l’écosystème React sont le temps réel et la persistance*. La relation entre ces 2 domaines provient du fait qu’ils sont tous deux en charge de la gestion des états.
* “Si vous ne connaissez pas ce mot, ne vous inquiétez surtout pas : au sens général, il s’agit simplement du terme utilisé pour décrire le fait de stocker des données d’une application de manière… persistante ! Autrement dit, de les sauvegarder afin qu’elles ne disparaissent pas lorsque le programme se termine. Rien de bien compliqué, en somme.” — Médéric Munier
Afin d’implémenter du temps réel, le serveur à besoin de connaître certains états du client, pour savoir quelles données mettre à jour ou quelles données envoyer.
- Christopher Chedeau
Il existe donc 1001 façons de générer, traiter, (re)trouver, acheminer, afficher nos données. React a fait le choix d’emprunter une direction commune à celle de ClojureScript dans une certaine mesure. Bien que le JavaScript natif ne supporte pas de base l’immutabilité, on a de bonnes raisons de garder espoir. La déclaration const introduite avec ES2015 par exemple, permet de créer une constante nommée et accessible uniquement en lecture. Attention par contre : seul l’identifiant ne peut pas être réaffecté, la valeur elle reste mutable. Tout ceci pour dire qu’on peut espérer une déclaration dans ES7 qui nous permettrait de déclarer une valeur immuable : notre code JavaScript en gagnerait en performance et en lisibilité. Mais vous vous en doutez : là je suis vraiment optimiste…
N’hésitez pas à vous abonner à cette publication, ou à mon compte Twitter (Charles D. Mangwa) et celui de Léo Le Bras, co-rédacteur pour Just React it ! : vous serez informé des prochains articles avant tout le monde ;) !
Prochaine partie : ReactEurope 2016 !
