Le keynote est présenté par @vjeux, qui travaille chez Facebook. Il insiste sur le fait que React a pour but de se concentrer sur le V de MVC. Il explique que React est construit autour de deux principe:
- Avoir la meilleure expérience utilisateur UX
- Avoir la meilleure expérience pour le développeur DX
Il a ensuite donné la vision de React, les sujets importants:
- Le routing avec React Routeur
- Comment traiter la préoblématique des requêtes entre le client et le serveur avec GraphQL
- Les outils de dev : webpack pour le déploiement babel
- La mobilité avec React Native
Il a remercié l'ensemble de la communauté pour l'adoption de React
Le second talk était à propos de comment faire les styles pour les composants. Pour faire simple:
- Le CSS n'est pas le style, le style peut être fait avec le CSS
- Les composants doivent être réutilisable, le problème c'est que dans les composants actuels: HTML + JS => Comportement et HTML + CSS => présentation
- On se retrouve avec beaucoup de classes CSS qui servent à décrire le comportement (
.is-open, ...) - Le principal problème c'est que le composant n'est pas fonctionnel sans sa feuille de style, et que l'on se retrouve à mettre beaucoup de code pour gérer le comportement du css dans le composant.
- Il faut donc faire porter le style lié au comportement par le compsant pour que ce dernier s'occupe de toute l'interface, ensuite il y a deux options: le css pour gérer l'apparance, ou carrément tout le css dans le composant
- React permet de gérer tout le css d'un composant via la propriété style
- Cette présentation était très intéressante
Flux est un pattern permettant d'architecturer correctement une application JS. Le présentateur de ce talk, qui réalise les sites jeuxvideo.com et millenium.org nous a présenté son architecture pour faire du flux côté serveur. Il est confronté à des problématiques de temps rééel pour les chats et de minimisation du traffic. A delà qu'il fasse une utilisation massive du web-socket, il a présenté comment il gérer la couche de communication entre le client et le serveur.
React Native est une libraire développée par Facebook afin de faire des applications native en utilisant React. Ceci permet de réutiliser les connaissance d'une personne qui sait faire un comosant React pour le web et de réaliser une application native en mutualisant une grosse partie du code. Facebook l'a utilisé sur plusieurs applications grand public et les ingénieurs qui les ont développés n'étaient pas familier avec le développement iOS et Android. Pour information, il s'agit bien d'une application native qui est générée et non d'une application web hybride. Le présentateur du talk nous a ensuité présenté une librairie développée par facebook pour faire des animations précises , simplement et sans modifier trop les compsants. Le résultat est assez impressionnant.
Graphql est un protocole de description entre le client et le serveur créé par facebook et open-sourcé le jour de la conférence. spec. Il y avait déjà eu une présentation rapide au mois de ja ncier dernier par facebook. GraphQL est un système qui permet de typper les données:
type Human {
id: String
name: String
homePlanet: String
}
Et ensuite de faire des requête sur des données arboressante de manière efficace:
- En ne ramenant pas tous les champs
- En ramenant des objets documentaires de manière efficace (pas tout l'objet d'un coup)
Par exemple:
query HeroNameAndFriendsQuery {
hero {
id
name
friends {
id
name
}
}
}
Retourne la réponse
{
"hero": {
"id": "2001",
"name": "R2-D2",
"friends": [
{
"id": "1000",
"name": "Luke Skywalker"
},
{
"id": "1002",
"name": "Han Solo"
},
{
"id": "1003",
"name": "Leia Organa"
}
]
}
}
Cette technique permet: une description des ressources très efficace, une utilisation par des clients multiples d'une API évolutive sans tout casser. Une description des ressources nécessaires côté client de manière très claire et un catalogue des ressources sur le serveur. Elle permet une minimisation des aller-retours entre le client et le serveur tout en restant efficace côté client. Facebook utilise cette technologie en production depuis 2 ans. Il faut donc que :
- le client effectue des requêtes de type GRAPHQL
- Que le serveur soit capable de les traiter
Ce talk présente quelles erreurs on peut faire en arrivant sur React. Quelle approche il faut avoir pour travailler de manière react. Il est présenté par une personne s'occupant de React routeur et explique également les choses à venir de ce côté.
La personne qui fait le talk a développé React hot loader. Qui comme son nomm l'indique permet de remplacer du code React a chaud. Il a ensuite présenté Redux qui est une librairie permettant de faire du flux en changeant l'approche:
Flux:
Actiion -> Dispatcher -> Store, Store, Store -> Component
Redux:
Actiion -> f(data)**f(data) -> Component
En gros plutôt que de passer par un cycle de gestion des données évenmentiel, il propose d'utiliser l'approche programmation focntionnelle et de concidéere les store comme des reducer sur les données.
Comme ça on simplifie la lecture, le debug et les points d'injections dans la chaîne de traitement.
Il a ensuite fait la démo d'une fenêtre de déboggage lié à ses stores.
Vraiment très interessant dans l'approche.
Relay est un framework construit pour fonctionner avec la paire React et GraphQL. (Il a déjà été présenté à la dernière conf React par Facebook au mois de Janvier, ils ont prévus de le rendre open source en aôut) L'approche est la suivante: Les compoosants expriment leurs besoins en terme de données. En prarique il expriment une requête graphQL un peu sur le même mode que je jsx. Ensuite les composants principaux sont rendus par des wrappers de manière transparente et quand ils sont prêt et ont recus leurs données. L'approche est encore une fois en mode programmation fonctionnelle, l'objectif est de faire ce qu'ils ont réussi à faire avec React pour les composants du côté des API et du requêtage. C'était super instructif, et très clair dans les explications et le pourquoi ils font tout ça.
Alors, comme React se base sur un DOM virtuel, il est possible de rendre d'autres choses que le DOM HTML: du svg, du canvas, il y en a qui ont pensé à du WebGL, et même à faire une application pour la console. La motivation principale est de montrer que les principes du composant / props / state sont tès simple et que l'on peut ajouter des points de capture et étendre le fonctionnement très simplement. Après pour faire une application console, de mon point de vue l'interêt est limité.
Dans la foulée du talk précédent. Ce talk a surtout parlé du DOM virtuel, des optimisations réalisés et en cours de travail. Ils ont été surpris par l'adoption rapide et l'extension des possibilités. Ils ont prévus de faire des améliorations sur la partie CSS. Comme la personne présentant est Core developer sur React, il y a eu plein de questions autour du moteur de diff du DOM, et de ce qu'ils souhaitaient faire pour les prochaines versions. Ils ont du coup annoncé que pour la version 0.14beta, le rendu dans le DOM et les composants seraient dans deux sous libs séparés.