Comprendre le modèle de flux

12

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)?

mfrachet
la source
1
Un lien vers ce dont vous parlez précisément serait utile. Voulez-vous dire ce "modèle de flux"? fluxxor.com/what-is-flux.html
DougM
Flux n'est rien de plus que le modèle de publication / abonnement avec une contrainte que toutes les données passent d'abord par le répartiteur. Cela garantit que les données ne remontent pas (et provoquent de la confusion). Des choses comme «Store», «Action», etc. ne sont qu'une autre façon de dire les composants du système et les données qui sont transmises.
kiwicomb123

Réponses:

23

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

entrez la description de l'image ici

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

Dhaval Patel
la source
Mon premier problème est que l'état permet à l'application d'avoir différentes données des entités API distantes: - /
mfrachet
que voulez-vous dire par état permet? partout où émettre un changement appelé, il sera appelé React View et à nouveau appelé méthode de changement d'état
Dhaval Patel
Admettre que je construis une application avec flux. Je traite avec une API, puis j'enregistre les données à l'intérieur de mes magasins. Que faire si un utilisateur modifie les données distantes? J'aurai une différence entre le client et le serveur
mfrachet
maintenant, où puis-je trouver pourquoi. Si tout le répartiteur et le magasin sont en train de faire, c'est pourquoi ils ne peuvent pas directement mettre à jour la vue. pourquoi il y a des intermédiaires
Muhammad Umer
@MuhammadUmer: Dispatcher en est un pour l'application et le magasin est basé sur le composant dans l'application afin de supprimer les intermédiaires de redondance ont été introduits
Dhaval Patel
1

À 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?)

Davislor
la source
0

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.

kiwicomb123
la source