Comprendre le modèle de flux

J'étudie actuellement le modèle de flux et il y a quelque chose que je ne peux pas comprendre concernant les magasins .

Quels sont-ils exactement?

J'ai lu de nombreux articles, et il semble que cela concerne le domaine.

Est-ce à dire qu'il s'agit de la partie "abstraite" liée aux appels api ou backend?

Ce n'est pas très clair pour moi.

Edit: Serait-ce la même chose que l'usine angulaire? Récupérer des données distantes, effectuer une tâche commerciale ou stocker certains états d'application (utilisateur actuel connecté par exemple)?

Ok, laissez-moi vous expliquer étape par étape

1 Qu'est-ce que Flux?

• Un motif
• Répartiteur centralisé
• Flux de données unidirectionnels
• Élément de liste

Ils l'appellent Flux pour une raison aussi.

Implémentations de flux

• Flux de Facebook
• Alt
• Reflux
• Démonter
• NuclearJS
• Fluxible

Un chat avec Flux

Réagissez : Hey Action, quelqu'un a cliqué sur ce bouton "Enregistrer le cours".

Action : Merci de réagir! J'ai enregistré un créateur d'actions auprès du répartiteur, de sorte que le répartiteur doit veiller à informer tous les magasins concernés.

Dispatcher : Laissez-moi voir qui se soucie de la sauvegarde d'un cours. Ah! On dirait que le magasin a enregistré un rappel avec moi, alors je vais lui faire savoir.

Magasin : Salut répartiteur! Merci pour la mise à jour! Je mettrai à jour mes données avec la charge utile que vous avez envoyée. Ensuite, j'émettrai un événement pour les composants React qui importent.

Réagissez : Ooo! De nouvelles données brillantes du magasin! Je mettrai à jour l'interface utilisateur pour refléter cela!

API Flux

register (fonction callback) - «Hey dispatcher, lance-moi quand des actions se produisent. -Boutique"

unregister (string id) - «Hey dispatcher, arrête de t'inquiéter de cette action. -Boutique"

waitFor (array ids) - «Mettez d'abord à jour ce magasin. -Boutique"

dispatch (objet payload) - «Hey dispatcher, informe les magasins de cette action. -Action"

isDispatching () - "Je suis en train de distribuer des rappels en ce moment."

de sorte que la question soulevée dans notre esprit est

Alors Flux est un modèle de publication-abonnement?

Pas assez.

Diffère de deux manières:

1.Chaque charge utile est envoyée à tous les rappels enregistrés.

2.Les rappels peuvent attendre d'autres rappels

Sommaire

Le flux est un modèle pour les flux de données unidirectionnels Les actions encapsulent les événements Dispatcher est un hub central qui contient les rappels Les magasins conservent l'état de l'application De nombreuses implémentations

À la recherche d'un exemple simple ( https://github.com/facebook/flux/tree/master/examples/flux-todomvc/ ), "les magasins gèrent l'état de l'application pour un domaine particulier au sein de l'application." Autrement dit, ils contiennent des données sur l'état d'un aspect de l'application et tout le code pour le modifier. Chaque fois qu'il y a une nouvelle mise à jour du répartiteur, tous les magasins la voient, ils décident comment mettre à jour leurs données en réponse, puis ils notifient aux vues que les données ont changé. Dans les exemples, les magasins contiennent des éléments tels que «liste des fils invisibles» (où le répartiteur les informe qu'un nouveau message est arrivé ou qu'un ancien a été lu, et que les vues affichent les fils de message à l'utilisateur) et «temps de lecture actuel et Etat."

Plus techniquement: ils sont la couche intermédiaire du framework qui enregistre les rappels avec le Dispatcher pour recevoir les mises à jour, puis avertit les vues lorsque l'état des données change. (Les vues peuvent ensuite renvoyer des actions au Dispatcher.) Il existe une interface abstraite qu'elles implémentent, où chaque magasin enregistre un rappel avec le Dispatcher et diffuse des événements vers les vues, mais chaque magasin semble représenter un domaine spécifique de manière concrète. (Y a-t-il des contre-exemples?)

Les magasins sont des zones du code qui stockent l'état de l'application et la logique complexe. Une raison à cela est que plusieurs vues utiliseront probablement les mêmes données, mais les afficheront d'une manière différente, ou afficheront certaines données, mais pas toutes, pour un domaine particulier. Par exemple, un utilisateur se connecte et vous recevez son prénom, nom, email, photo, ville, numéro d'adresse, numéro de téléphone, etc. Ces informations sont affichées sur des vues séparées. Plutôt que de dupliquer des données sur plusieurs vues, nous pouvons utiliser un magasin appelé UserStore qui stocke les données pour l'utilisateur. Cela simplifie le système en donnant "un endroit pour effectuer un changement" chaque fois que la logique ou les données stockées doivent être modifiées. Il existe de nombreuses autres raisons d'utiliser un magasin, mais c'est la plus évidente à mon avis.