Redux & RxJS, des similitudes?
Je sais que Redux est une meilleure "implémentation" de Flux, ou mieux dire que c'est une refonte pour simplifier les choses (gestion de l'état de l'application).
J'ai beaucoup entendu parler de programmation réactive (RxJS), mais je n'ai pas encore plongé pour l'apprendre.
Ma question est donc la suivante: existe-t-il une intersection (quelque chose en commun) entre ces deux technologies ou sont-elles complémentaires? ... ou totalement différent?
En bref, ce sont des bibliothèques très différentes à des fins très différentes, mais oui, il existe de vagues similitudes.
Redux est un outil de gestion d'état dans toute l'application. Il est généralement utilisé comme une architecture pour les interfaces utilisateur. Pensez-y comme une alternative à (la moitié des) angulaires.
RxJS est une bibliothèque de programmation réactive. Il est généralement utilisé comme outil pour effectuer des tâches asynchrones en JavaScript. Pensez-y comme une alternative aux promesses.
La programmation réactive est un paradigme (manière de travailler et de penser) où les changements de données sont observés à distance. Les données ne sont pas modifiées à distance.
Voici un exemple de modifié de loin:
// In the controller.js file
model.set('name', 'George');
Le Modèle est modifié du contrôleur.
Voici un exemple de observé de loin:
// logger.js
store.subscribe(function (data) {
console.log(data);
});
Dans le Logger, nous observons les modifications de données qui se produisent dans Store (à distance) et écrivons dans la console.
Redux utilise juste un peu le paradigme réactif: le magasin est réactif. Vous ne définissez pas son contenu à distance. C'est pourquoi il n'y a pas de store.set() dans Redux. Le magasin observe les actions à distance et se modifie. Et le magasin permet aux autres d’observer ses données à distance.
RxJS utilise également le paradigme Reactive, mais au lieu d’être une architecture, il vous donne les blocs de construction de base, Observables, pour accomplir ce modèle "d’observation à distance".
Pour conclure, des choses très différentes pour des buts différents, mais partagez quelques idées.
Ce sont des choses très différentes.
RxJS peut être utilisé pour faire de la programmation réactive et est une bibliothèque très complète avec plus de 250 opérateurs.
Et Redux est comme décrit dans le dépôt github "Redux est un conteneur d’états prévisible pour les applications JavaScript".
Redux est juste un outil pour gérer l'état dans les applications. Mais en comparaison, vous pouvez créer une application complète dans seulement RxJS.
J'espère que cela t'aides :)
Pour résumer:
Redux: Bibliothèque inspirée par Flux utilisée pour Gestion des états .
RxJS: Il s'agit d'une autre bibliothèque Javascript basée sur la philosophie de programmation réactive, utilisée pour traiter les "flux" (Observables, etc.) [Lisez à propos de la programmation réactive pour comprendre les concepts de flux].
Je voulais juste ajouter quelques différences pragmatiques par rapport au code RxJS inspiré de Redux.
J'ai mappé chaque type d'action sur une instance de sujet . Chaque composant stateful aura un sujet qui est ensuite mappé sur une fonction de réduction . Tous les flux de réduction sont combinés avec merge et scan génère alors l'état . la valeur par défaut est définie avec startWith juste avant la scan. J'ai utilisé publishReplay(1) pour les états, mais je pourrais l'enlever plus tard.
La fonction de rendu pur de réaction sera uniquement à l'endroit où vous produisez des données d'événement en envoyant tous les producteurs/sujets.
Si vous avez des composants enfants, vous devez décrire comment ces états sont combinés dans le vôtre. combineLatest pourrait être un bon point de départ pour cela.
Différences notables dans la mise en œuvre:
Pas de middleware, juste des opérateurs rxjs. Je pense que c'est le plus gros pouvoir et le plus faible. Vous pouvez toujours emprunter des concepts, mais j'ai du mal à obtenir l'aide de communautés homologues telles que redux et cycle.js car il s'agit d'une solution personnalisée supplémentaire. C'est pourquoi je dois écrire "je" au lieu de "nous" dans ce texte.
Aucun commutateur/cas ou chaîne pour les types d'action. Vous avez une manière plus dynamique de séparer les actions.
les rxjs peuvent être utilisés ailleurs, et ne sont pas contenus dans la gestion des états.
Moins de producteurs que de types d'action (?). Je n'en suis pas sûr, mais vous pouvez avoir de nombreuses réactions dans les composants parents qui écoutent les composants enfants. Cela signifie un code moins impératif et moins complexe.
Vous possédez la solution. Pas de cadre nécessaire. Bon et mauvais. De toute façon, vous finirez par écrire votre propre framework.
C'est beaucoup plus fractal et vous pouvez facilement vous abonner aux modifications d'un sous-arbre ou de plusieurs parties de l'arbre d'état de l'application.
- Devinez comme il est facile de faire des épopées comme le fait redux-obseravble? Vraiment facile.
Je travaille également sur des avantages bien plus importants dans lesquels les composants enfants sont décrits comme des flux. Cela signifie que nous ne devons pas comploter les états parent et enfant dans les réducteurs, car nous pouvons simplement ("juste") combiner de manière récursive les états en fonction de la structure du composant.
Je pense aussi à sauter et réagir avec snabbdom ou autre jusqu'à ce que React gère mieux les états réactifs. Pourquoi devrions-nous construire notre État à la hausse simplement pour le décomposer à nouveau avec des accessoires Je vais donc essayer de faire une version 2 de ce modèle avec Snabbdom.
Voici un extrait de code plus avancé mais de petite taille dans lequel le fichier state.ts construit le flux d’état. C'est l'état du composant ajax-form qui obtient un objet de champs (entrées) avec des règles de validation et des styles css. Dans ce fichier, nous utilisons simplement les noms de champs (clés d'objet) pour combiner tous les états des enfants dans l'état du formulaire.
export default function create({
Observable,
ajaxInputs
}) {
const fieldStreams = Object.keys(ajaxInputs)
.map(function onMap(fieldName) {
return ajaxInputs[fieldName].state.stream
.map(function onMap(stateData) {
return {stateData, fieldName}
})
})
const stateStream = Observable.combineLatest(...fieldStreams)
.map(function onMap(fieldStreamDataArray) {
return fieldStreamDataArray.reduce(function onReduce(acc, fieldStreamData) {
acc[fieldStreamData.fieldName] = fieldStreamData.stateData
return acc
}, {})
})
return {
stream: stateStream
}
}
Même si le code ne dit pas grand-chose de manière isolée, il montre comment vous pouvez créer un état ascendant et comment créer facilement des événements dynamiques. Le prix à payer est que vous devez comprendre un style de code différent. Et j'adore payer ce prix.
Redux est juste une bibliothèque de gestion d’états avec des standards bien définis pour les opérations de mise à jour. Dans la mesure où vous vous en tenez aux normes, vous pouvez garder votre flux de données sain et facile à raisonner. Il offre également la possibilité d'améliorer le flux de données avec les middlewares et les optimiseurs de magasins.
RxJS est une boîte à outils pour la programmation réactive. Vous pouvez réellement considérer tout ce qui se passe dans votre application comme un flux. RxJS fournit un ensemble d'outils très riche pour gérer ces flux.
Où RxJS et Redux s'interceptent? Dans redux, vous mettez à jour votre état avec des actions et ces actions peuvent évidemment être traitées comme des flux. En utilisant un middleware tel que redux-observable (vous n'avez pas à le faire), vous pouvez implémenter votre "logique métier" de manière réactive. Une autre chose est que vous pouvez créer un observable à partir de votre magasin Redux, ce qui peut parfois être plus facile que d’améliorer.
Vous pouvez "implémenter" Redux dans une ligne de RxJS . Si vous songez à Rx pour d'autres raisons (par exemple, ne vous inquiétez pas, utilisez-le sur le serveur et sur le client), ignorez Redux et lancez toutes les applications.