Motivation
Comme les exigences pour les applications JavaScript one-page sont devenues de plus en plus compliquées, notre code doit gérer plus d'états que jamais. Cet état peut inclure des réponses de serveurs et des mises en cache de données, ainsi que des données créées localement qui n'ont pas encore été sauvegardées sur le serveur. L'état de l'interface utilisateur augmente aussi en complexité, comme nous avons besoin de gérer les routes actives, les onglets sélectionnés, l'affichage des chargements, le contrôle de la pagination, etc.
Gérer cet état en constante évolution est difficile. Si un modèle peut mettre à jour un autre modèle, alors une vue peut mettre à jour un modèle, qui met à jour un autre modèle, et ça, à son tour, peut provoquer une autre vue à mettre à jour. À un moment donné, vous ne comprenez plus ce qui arrive dans votre application, car vous avez perdu le contrôle sur le quand, le pourquoi, et le comment de l'état de l'application. Quand un système est opaque et non déterministe, c'est compliqué de reproduire les bugs ou d'ajouter de nouvelles fonctionnalités.
Comme si ce n'était pas assez, considérez les nouvelles exigences devenant courantes dans le développement d'application front-end. En tant que développeurs, nous sommes censés gérer les mises à jour, le rendu côté serveur, récupérer des données avant d'effectuer des redirections, etc. Nous nous trouvons à essayer de gérer une complexité que nous n'avions jamais eu à traiter auparavant, et nous nous posons inévitablement la question: est-il temps d'abandonner? La réponse est non.
Cette complexité est difficile à gérer, car nous mélangeons deux concepts qui sont très difficiles à appréhender pour l'esprit humain : la mutation et l'asynchrone. Je les appelle Mentos et Coca. Les deux peuvent être génial séparé, mais ensemble ils créent un désordre. Les bibliothèques comme React essaient de résoudre le problème dans la couche de vue en supprimant à la fois l'asynchronisme et la manipulation directe du DOM. Toutefois, gérer l'état de vos données reste de votre responsabilité. C'est là que Redux entre en jeu.
Suivre les pas de Flux, CQRS, et Event Sourcing, Redux tente de rendre les mutations d'état prévisibles en imposant certaines restrictions sur comment et quand les mises à jour doivent se produire. Ces restrictions sont reflétées dans les trois principes de Redux.