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 des applications).

J'ai beaucoup entendu parler de la programmation réactive (RxJS), mais je n'ai pas encore plongé pour l'apprendre.

Ma question est donc la suivante: y a-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 y a de vagues similitudes.

Redux est un outil de gestion de l'état dans toute l'application. Il est généralement utilisé comme architecture pour les interfaces utilisateur. Considérez-le comme une alternative à (la moitié de) Angular.

RxJS est une bibliothèque de programmation réactive. Il est généralement utilisé comme un outil pour accomplir des tâches asynchrones en JavaScript. Pensez-y comme une alternative aux promesses.

La programmation réactive est un paradigme (façon 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 modification à distance :

// In the controller.js file
model.set('name', 'George');

Le modèle est modifié à partir du contrôleur.

Voici un exemple d' observation à distance :

// logger.js
store.subscribe(function (data) {
    console.log(data);
});

Dans le Logger, nous observons les changements de données qui se produisent dans Store (à distance) et écrivons dans la console.

Redux utilise un peu le paradigme réactif: le Store est réactif. Vous ne définissez pas son contenu à distance. C'est pourquoi il n'y store.set()en a pas dans Redux. Le Store observe les actions à distance et se modifie. Et le Store permet aux autres d'observer ses données à distance.

RxJS utilise également le paradigme réactif, mais au lieu d'être une architecture, il vous donne des blocs de construction de base, les observables , pour accomplir ce modèle "d'observation à distance".

Pour conclure, des choses très différentes à des fins différentes, mais partager 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 sur le dépôt github "Redux est un conteneur d'état 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 en RxJS uniquement.

J'espère que cela t'aides :)

Redux est juste une bibliothèque de gestion d'état livrée avec des normes bien définies 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 permet également d'améliorer le flux de données avec des middlewares et des exhausteurs de magasin.

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 offre un ensemble d'outils très riche pour gérer ces flux.

Où intercepte RxJS et Redux? En redux, vous mettez à jour votre état avec des actions et évidemment ces actions peuvent être traitées comme des flux. En utilisant un middleware comme redux-observable (vous n'êtes pas obligé), vous pouvez implémenter votre soi-disant "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'utiliser un enhancer.

Pour le dire en bref:

Redux: Bibliothèque inspirée de Flux utilisée pour la gestion des états .

RxJS: C'est une autre bibliothèque Javascript basée sur la philosophie de programmation réactive, utilisée pour traiter les "Streams" (Observables, etc.) [Lire la programmation réactive pour comprendre les concepts Stream].

Je voulais juste ajouter quelques différences pragmatiques par rapport au moment où j'ai créé du code RxJS inspiré de Redux.

J'ai mappé chaque type d'action sur une instance de sujet. Chaque composant avec état aura un sujet qui est ensuite mappé dans une fonction de réduction. Tous les flux de réducteur sont combinés avec merge, puis scansortent l'état. La valeur par défaut est définie startWithjuste avant le scan. J'ai utilisé publishReplay(1)pour les états, mais je pourrais le supprimer plus tard.

La fonction react pure render sera uniquement le lieu 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. combineLatestpourrait ê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 la plus grande puissance et faiblesse. Vous pouvez toujours emprunter des concepts, mais j'ai du mal à obtenir de l'aide de communautés sœurs comme redux et cycle.js car c'est encore une autre solution personnalisée. C'est pourquoi j'ai besoin d'écrire «je» au lieu de «nous» dans ce texte.

• Aucun commutateur / boîtier ou chaînes pour les types d'action. Vous disposez d'une manière plus dynamique de séparer les actions.

• rxjs peut être utilisé comme un outil ailleurs et n'est pas contenu dans la gestion des états.

• Moins de producteurs que de types d'actions (?). Je ne suis pas sûr de cela, mais vous pouvez avoir de nombreuses réactions dans les composants parents qui écoutent les composants enfants. Cela signifie moins de code impératif et moins de complexité.

• Vous possédez la solution. Aucun cadre nécessaire. Bon et mauvais. Vous finirez par écrire votre propre framework de toute façon.

• C'est beaucoup plus fractal et vous pouvez facilement vous abonner aux modifications à partir d'un sous-arbre ou de plusieurs parties de l'arborescence d'état de l'application.

  • Devinez à quel point il est facile de faire des épopées comme le font redux-obseravble? Vraiment facile.

Je travaille également sur des avantages beaucoup plus importants où les composants enfants sont décrits comme des flux. Cela signifie que nous n'avons pas à compléter les états parent et enfant dans les réducteurs, puisque nous pouvons simplement ("juste") combiner récursivement les états en fonction de la structure du composant.

Je pense aussi à ne pas réagir et à aller avec snabbdom ou autre chose jusqu'à ce que React gère mieux les états réactifs. Pourquoi devrions-nous construire notre état vers le haut juste pour le décomposer à nouveau via des accessoires? Je vais donc essayer de faire une version 2 de ce pattern avec Snabbdom.

Voici un petit extrait de code plus avancé où le fichier state.ts construit le flux d'état. C'est l'état du composant de forme ajax 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 champ (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
  }
}

Bien que le code ne dise pas grand-chose isolément, il montre comment vous pouvez créer un état vers le haut et comment vous pouvez produire facilement des événements dynamiques. Le prix à payer est que vous devez comprendre un style de code différent. Et j'aime payer ce prix.