Skip to content

Instantly share code, notes, and snippets.

@D34THWINGS
Last active May 25, 2016 14:35
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save D34THWINGS/581efe5b76d8821b2b6ac20365360115 to your computer and use it in GitHub Desktop.
Save D34THWINGS/581efe5b76d8821b2b6ac20365360115 to your computer and use it in GitHub Desktop.

React et Architecture Flux

Introduction

Flux est une architecture pour application web que Facebook a proposé pour construire des applications avec React. Elle est née de plusieurs besoins que la communauté frontend a rencontré lors du développement d'application web massives comprenant un grand nombre de données. Ces besoin sont les suivants :

  • Eviter la dette technique / possibilité d’évolution aisée
  • Réduire le nombre de dépendance entre les différents Services/Controllers de l'application
  • Empêcher les effets de bords indésirables
  • Savoir précisément quel est l'état de la donnée à tout instant
  • Gérer une grande quantité de données et de changement sur celle-ci
  • Augmenter la possibilité de réutiliser du code
  • Performances

Voici donc quelques solutions clées pour y répondre :

  • Immutabilité
  • Flux unidirectionnel de données
  • Conteneurs de stockages isolés pour les données
  • Libraries découpées/légères

Ces points sont la base de l'architecture Flux et de la philosophie React en général.

Flux

Immutabilité

Avant de rentrer dans le détail de l'architecture, il est important de parler d'immutabilité. C'est un principe qui consiste à ne jamais modifier un objet. En effet modifier un objet en JavaScript peut entrainer des effets de bords indésirables quand ils sont propagés par référence. On ne sait alors plus d'où ils viennent ni qu'est-ce qui a été changé. Il est donc recommandé à la place de faire des copies d'objet et de modifier cette copie à la place, puis retourner cette copie à la place de l'original.

The big picture

L'architecture Flux est simple car elle se présente sous la forme d'un cycle. Chaque action de l'utilisateur provoque un tour complet de cette boucle. Cette boucle se présente de la manière suivante :

Architecture Flux

Interface

L'Interface est le point d'entrée de l'architecture. Elle est votre librairie de gestion d'interface préférée (React, VDOM, etc...). Celle-ci va être en charge de capter les actions de l'utilisateur quelle quel soit.

Action

A partir de cette action utilisateur (clic par exemple) on va créer un objet que l'on va appeler tout simplement une Action. Cet objet contient les informations nécessaires à identifier l'action de l'utilisateur dont une obligatoire, à savoir le type d'action.

Ce type va être un identifiant qui va permettre de savoir qu'est-ce que l'utilisateur a fait dans l'interface (ex: 'DELETE_TODO'). Le reste des informations est le context de l'action, par exemple l'identifiant du TODO à supprimer. Ces informations de context devront se trouver dans le champ payload de notre objet action.

Voici notre action au complet :

const incrementAction = {
  type: 'INCREMENT',
  payload: 4
}

Dispatcher

Ces actions sont ensuite envoyées à un Dispatcher. C'est un objet implémentant le pattern Observer/Observable auquel on peut envoyer des évènemen. Ces évènements en l'occurence seront nos actions utilisateurs.

Il est aussi possible de se souscrire au Dispatcher pour être notifié de ces même évènements. C'est une sorte de proxy pour nos actions, un endroit unique où tout le monde pourra savoir quand l'utilisateur intéragi et comment avec l'interface.

Store

Vienent ensuite les Stores qui sont des objets responsables du stockage de la donnée dans l'application. Les store vont souscrire aux Dispatchers de leurs choix afin de savoir à quel moment l'utilisateur execute telle ou telle action.

En fonction de chaque action reçu depuis le dispatcher et de l'état courant de la donnée stocké en son sein, le store va créer un nouvel état de l'application. Celui-ci viendra ensuite écraser l'état précédent.

Le store est lui aussi un Observable qui va notifier tous ses subscribers lors d'un changement de donnée. Donc pour clôturer la boucle l'interface souscrit à un ou plusieurs Store, pour savoir quand elle doit se mettre à jour.

Redux

Il existe une implémentation très répandue de l'architecture Flux appelé Redux. Cette implémentation ne contient qu'un seul store, un seul dispatcher et possède de très bon outils pour debugger l'état de votre application (extension Chrome).

React

React est une librairie crée par Facebook permettant de gérer le DOM et ainsi de construire des pages dynamiques. Elle utilise le concept de virtual DOM afin de produire des rendus rapides consommant peu de performances.

Le code de React est isomorphique, ce qui veut dire qu'il peut-être aussi bien exécuté côté server dans Node que côté client dans le navigateur. Ceci est pratique pour gérer les problématique de SEO et faire un pré-rendu de l'application côté serveur lors de la première visite de l'utilisateur (permet d'éviter d'afficher un loader).

React peut être utilisé en ES5, ES6 et possède aussi une syntaxe appelée JSX permettant de simplifier le développement (transpiler Babel requis).

Retour d'expérience

Après un premier projet conséquent en React/Redux, voici les plus de cette architecture couplée à React :

  • Léger : Contrairement à un framework All-in-One type Angular, on va pouvoir choisir une à une les librairies dont on a besoin ce qui permet d'alléger le build.
  • Scale bien : Peu importe le nombre de composant, l'application reste fluide et rapide.
  • Survie très bien dans le temps : Même au bout de quelques mois de dev, l'application reste facile à debug et l'ajout de fonctionnalité se fait rapidement.
  • Syntaxe All-in-one : HTML/CSS/JS dans un même fichier. Cela permet de créer de tout petit composant faciles à réutiliser avec un seul import.

Nous avons néanmoins quelques retours négatifs :

  • Nécéssite d’être rigoureux : Il n'existe pas de vrai guideline à l'heure actuelle, il est donc facile de partir dans tous les sens. Il est donc recommandé de se fixer dès le départ sur les méthodes à adopter.
  • Boilerplate important : Avant de pouvoir commencer à coder des fonctionalités il va falloire mettre en place une bonne quantité d'outils et de librairie ce qui peut freiner certains développeurs.
  • Coût d’accès : Celui-ci est d'autant plus élevé que le boilerplate va vous ralentir car il faudra bien compter 3 à 4 jours homme pour mettre en place votre structure de base.
  • Ne gère absolument rien out-of-the-box : Ceci amène à faire beaucoup de choix techniques pour trouver quelles librairie sera la meilleure pour effectuer telle ou telle chose (requêtes XHR par exemples)

Pour résumer, c'est un univers que je réserverait à des développeurs JavaScript confirmés qui ont une bonne connaissance des architectures d'application. Une fois le projet lancé ça devient très agréable de travailler avec et surtout rapide.

Aller plus loin

Pour ceux à la recherche de veille complémentaire, voici quelques sujets liés à React qui peuvent être intéressant de traiter :

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment