Apollo vs Redux - rendu avec données

Apollo et Redux sont 2 bibliothèques populaires utilisées avec React. Ils sont inclus pour diverses raisons, mais principalement pour:
1. Gérer un magasin
2. Assistance au traitement de la récupération des données
3. Déclencher tout re-rendu avec des accessoires mis à jour

Mais quels mécanismes utilisent-ils sous le capot pour ce faire, et comment diffèrent-ils en ce qui concerne la manipulation des accessoires et le rendu?

J'ai décidé d'enquêter et ci-dessous est le produit de cela.

TLDR;

Apollo utilise un observable et force manuellement un nouveau rendu, lisant l'observable actuel pour les données au point de rendu.

Redux utilise également un observable, mais met à jour l'état local pour ses abonnés à l'aide de notifications d'observateur.

Observables

Les observables sont des éléments importants à aborder en premier. Il s'agit d'une nouvelle primitive asynchrone dotée de puissantes propriétés. Un exemple de base est ci-dessous.

  1. Créez votre observable à partir d'une fonction d'abonnement
const subscriptionFunction = (observateur) => {
   // faire des trucs, pourrait être asynchrone.
   observer.next ("Appel avec quelques données");
   observer.complete ();
   return () => console.log ("Se désinscrire")
}
const ourObservable = new Observable (souscriptionFonction);

2. Abonnez-vous à votre observable. Cela invoquera la fonction d'abonnement.

const subscriber = ourObservable.subscribe ({
   next (x) {console.log (x)}, // "Appel avec des données"
   error (err) {console.log ("Erreur de terminaison reçue du
   séquence. ")},
   complete () {console.log ("Le flux s'est terminé avec succès.")}
});
subscriber.unsubscribe (); // "Désabonnement"

Fondamentalement, nous pouvons définir une relation 1 à plusieurs entre les objets. Lorsque l'état change pour le parent observable, ses dépendants (les observateurs) sont informés et mis à jour.

Ils ont plusieurs propriétés puissantes, notamment être paresseux, annulables et peuvent s'exécuter plusieurs fois dans une séquence.

Découvrez zen-observable pour les utiliser de manière conforme aux spécifications dès aujourd'hui.

Commençons par Apollo

Apollo utilise la récupération dans une fonction d'abonnement à Observables (trouvez tous les détails sur les fonctions internes d'Apollo dans une récente conférence que j'ai faite ici). L'Observable sert également de magasin pour les données normalisées.

Lors de la réception de la réponse d'une requête HTTP, le Store est mis à jour puis un «forceRender ()» est déclenché (méthode Reacts pour déclencher manuellement un nouveau rendu à l'intérieur d'un composant donné).

Enfin, en utilisant le «modèle d'accessoire de rendu», les enfants sont rendus avec des données de l'Observable actuel. Il convient de noter que l'état React n'a pas été utilisé du tout ici.

Voir ci-dessous pour une ventilation des événements sur un chargement de page avec un composant de requête de base.

Anatomie complète d'un chargement de page avec Apollo

Maintenant sur Redux

Avec Redux, nous ignorerons le mécanisme de récupération HTTP réel (en supposant que des thunks ou des sagas sont utilisés pour cela) et nous concentrerons sur les mises à jour du magasin et les rendus de composants.

Lorsqu'un composant se connecte (), il est ajouté à la liste des abonnés du Store Observable (plus d'informations sur le Redux Store Observable ici).
Lorsqu'un réducteur change d'état dans le Store, tous les abonnés sont avertis et exécutent un «setState ()».

Le résultat est le composant connecté et ses enfants sont restitués avec des accessoires mis à jour.

Une version simplifiée de la connexion de Redux est ci-dessous:

classe Connect étend Component {
     trySubscribe () {
        this.unsubscribe =
          this.store.subscribe (this.handleChange.bind (this))
        this.handleChange ()
     }
     componentDidMount () {
       this.trySubscribe ()
     }
     handleChange () {
       const storeState = this.store.getState ()
       const prevStoreState = this.state.storeState
       // logique utilisant l'état de stockage et de réaction
       // si l'état du magasin a changé, mettre à jour l'état Reacts
       this.setState ({storeState})
     }
}

Sommaire

Je trouve fascinant que les deux bibliothèques utilisent Observables même si elles l'utilisent avec des mécanismes différents.

Je pense que si rien d'autre ne montre le genre de rôle qu'Observables aura dans l'avenir de Javascript. Ils sont actuellement à l'étape 1 de la proposition officielle (tous les détails à tc39 ici), donc j'espère atterrir bientôt. Compte tenu du type de pouvoir qu'ils apportent à la table (résoudre des problèmes que les promesses sont des flux parfois ne peuvent pas), il semble qu'il existe un bon nombre de scénarios qui leur conviendront bien.

Lire des exemples de travail d'entre eux dans la nature, comme celui de Redux et Apollo, est un excellent moyen d'en savoir plus à leur sujet.

Ensuite, je voudrais examiner les avantages et les inconvénients de ces approches et essayer de comprendre pourquoi ces bibliothèques ont choisi l'approche qu'elles ont choisie.

Si vous avez aimé cela, veuillez épargner un coup. Sinon, faites-moi savoir si vous avez des idées ou des commentaires. Merci :)