Architecture : Redux ou Fullstate

Dans le cadre de développement d'applications avec la bibliothèque React, il faut concevoir une architecture de data flow.

Les équipes de React ont proposé une architecture qu'ils ont appelé Flux. Il existe désormais des implémentations de cette architecture à travers des bibliothèques proposant une API pour faire circuler les données :

• création d'un store
• subscription (abonnement) des composants aux changements de ce store
• dispatch (répercution) d'actions

Le tout avec des principes permettant le voyage dans le temps (time travel), les tests, etc. (on retrouve la plupart de ces principes dans les architectures à base d'event sourcing et CQRS).

CQRS fits well with event-based programming models. It's common to see CQRS system split into separate services communicating with Event Collaboration. This allows these services to easily take advantage of Event Sourcing. — Martin Fowler, https://martinfowler.com/bliki/CQRS.html

Tout cela demande beaucoup de travail, de conception et de code et comme l'a très vite écrit l'un des auteurs de Redux : You Might Not Need Redux, Dan Abramov.

Voyons les différences entre une application simple implémentée au sein d'une architecture Flux avec Redux ou au sein d'une composant FullState.
Cette application propose :

• un formulaire pour écrire du texte
• un bouton permettant d'enregistrer le texte
• une zone de résultat affichant la version du texte de 2 manières :
  • la version originale respectant la casse
  • la version capitalisée

Quand utiliser Redux ?

1. Quand on veut partager des informations entre différents composants éloignés l'un de l'autre (et donc sans possibilité de mettre un composant wrapper) : Redux propose une centralisation de l'état de l'application
2. Quand on veut pouvoir persister un état, le recharger, permettre d'annuler une action, de rejouer un lot d'actions : Redux propose du time travel

Et n'oublions pas qu'un état centralisé ne doit pas être redondant (Single Source of Truth pour chaque élément du store) comme le montre Ryan Johnson dans Dissecting Twitter’s Redux Store.

À ne pas confondre avec l'un des trois principes de Redux qui exprime le besoin d'avoir un store unique (organisé grâce à combineReducers contrairement à ce qu'exprimaient les premières implémentations de l'architecture Flux, bien qu'il soit possible d'avoir plusieurs stores.

codesandbox

J'adore codesandbox, il me fallait un endroit pour le dire. Si vous voulez découvrir l'application à travers des exemples, regardez donc mes sandboxes.