web-dev-qa-db-fra.com

Meilleures pratiques de flux: stocke les actions de répartition, AJAX appels dans les API Web Utils?

enter image description here

Je comprends que cette image a été le guide ultime de la plupart, sinon de tous, les programmeurs Flux. Ayant ce flux à l'esprit, j'ai quelques questions:

  1. Est-il correct/fortement conseillé d'avoir tous mes $.ajax appels dans mon Web API Utils?
    • Les rappels appellent les créateurs d'actions, transmettant les données dans le processus
  2. Si je veux que mon Store fasse un appel AJAX, je dois d'abord appeler le Action Creator, non? Est-il fondamentalement incorrect d'appeler une fonction dans Web API Utils directement depuis Store?
  3. Existe-t-il une flèche virtuelle unilatérale se connectant de Store à Action Creators?
    • J'ai beaucoup d'opérations qui ne passent pas par des vues
  4. Quels sont les rappels entre Dispatcher et Store?
  5. Quelle est la API Web ici? Est-ce là que vous appliqueriez une API RESTful? Y a-t-il un exemple de cela quelque part?

  6. Est-il acceptable d'avoir une logique impliquée (pour savoir laquelle Action à envoyer) dans l'un de mes Action Creators? Fondamentalement, cette action reçoit la réponse de mon appel AJAX. Ceci est un extrait:

    var TransportActions = {
    receiveProxyMessage: function (message, status, xhr) {
        switch (message) {
            case ProxyResponses.AUTHORIZED:
                AppDispatcher.dispatch({
                    type: ActionTypes.LOGIN_SUCCESS,
                    reply: m
                });
                break;
            case ProxyResponses.UNAUTHORIZED:
                AppDispatcher.dispatch({
                    type: ActionTypes.LOGIN_FAIL,
                    reply: m
                });
                break;
            ...
        }
    }
}

J'ai vu beaucoup de réponses différentes en ligne, mais je ne sais toujours pas comment je les intégrerais toutes dans ma candidature. TYIA!

javascriptajaxreactjsreactjs-fluxflux
37
ton

Est-il correct/fortement conseillé d'avoir tous mes appels $ .ajax dans mes utilitaires Web API? Les rappels appellent les créateurs d'actions, transmettant les données au cours du processus.

Oui, vous devez regrouper toutes vos demandes dans une seule entité, c'est-à-dire les API Web Utils. Ils doivent envoyer les réponses afin que tout magasin puisse choisir d'agir en conséquence.

J'ai écrit un article de blog il y a quelque temps montrant une façon de gérer les demandes http://www.code-experience.com/async-requests-with-react-js-and-flux-revisited/

Si je veux que mon magasin effectue un appel AJAX, je dois d'abord appeler le créateur d'actions, n'est-ce pas? Est-il fondamentalement incorrect d'appeler une fonction dans Web API Utils directement à partir du magasin?

C'est une bonne question, et pour autant que je l'ai vu, tout le monde le fait un peu différemment. Flux (de Facebook) ne fournit pas de réponse complète.

Vous pouvez généralement adopter deux approches ici:

  1. Vous pouvez faire valoir qu'un magasin ne doit pas "demander" de données, mais simplement assimiler les actions et notifier la vue. Cela signifie que vous devez déclencher des actions de "récupération" dans les composants si un magasin est vide. Cela signifie que vous devrez vérifier sur chaque vue d'écoute de données si elle doit récupérer des données. Cela peut entraîner une duplication de code si plusieurs vues écoutent le même magasin.

  2. Les magasins sont "intelligents" dans le sens où s'ils sont invités à fournir des données, ils vérifient s'ils ont réellement un état à livrer. Si ce n'est pas le cas, ils indiquent aux API API de récupérer les données et de renvoyer un état en attente aux vues.

    Veuillez noter que cette "demande à l'API de récupérer les données" n'est PAS une opération basée sur le rappel, mais une opération "tirer et oublier". L'API enverra des actions une fois la demande renvoyée.

Je préfère l'option 2 à l'option 1, et j'ai entendu Bill Fisher de l'équipe Facebook dire qu'ils le faisaient aussi comme ça. (voir les commentaires quelque part dans le blog ci-dessus)

donc Non il n'est pas fondamentalement faux d'appeler l'API directement depuis le Store à mon avis.

Existe-t-il une flèche virtuelle unilatérale se connectant du magasin aux créateurs d'action?

Selon votre implémentation de Flux, il pourrait très bien y en avoir.

Quels sont les rappels entre Dispatcher et Store?

Ce sont les seules fonctions qui peuvent réellement changer l'état d'un magasin! chaque magasin enregistre un rappel auprès du répartiteur. Tous les rappels sont invoqués chaque fois qu'une action est envoyée. Chaque rappel décide s'il doit muter le magasin en fonction du type d'action. Certaines bibliothèques Flux essaient de vous cacher ce détail d'implémentation.

Quelle est l'API Web ici? Est-ce là que vous appliqueriez une API RESTful? Y a-t-il un exemple de cela quelque part?

Je pense que dans l'image, le rectangle de l'API Web représente le serveur réel, les API Utils sont ceux qui appellent le serveur (c'est-à-dire $ .ajax ou superagent). Il s'agit très probablement d'une API RESTful desservant les JSON.

Conseils généraux:

Flux est un concept assez vague et les implémentations exactes changent d'équipe en équipe. J'ai remarqué que Facebook a également changé certaines approches ici et là au fil du temps. Le cycle exact n'est pas strictement défini. Il y a cependant des choses assez "fixes":

  1. Il existe un répartiteur qui envoie toutes les actions à tous les magasins et autorise une seule action à la fois pour éviter l'enfer de la chaîne d'événements.
  2. Les magasins sont des récepteurs d'actions et tous les états doivent être modifiés par des actions.
  3. les actions sont "tirer et oublier" (pas de rappels!)
  4. Les vues reçoivent l'état du magasin et déclenchent des actions

D'autres choses se font différemment d'une implémentation à l'autre

33
Retozi
  1. Est-il correct/fortement conseillé d'avoir tous mes appels $ .ajax dans mes utilitaires Web API? Les rappels appellent les créateurs d'actions, transmettant les données au cours du processus.

Absolument.

  1. Si je veux que mon magasin effectue un appel AJAX, je dois d'abord appeler le créateur d'actions, n'est-ce pas? Est-il fondamentalement incorrect d'appeler une fonction dans Web API Utils directement à partir du magasin?

Tout d'abord, demandez-vous pourquoi votre magasin doit effectuer un appel API. La seule raison pour laquelle je peux penser est que vous voulez mettre en cache les données reçues dans les magasins (je le fais).

Dans les implémentations Flux les plus simples, toutes les actions sont créées uniquement à partir de la vue et du serveur. Par exemple, un utilisateur visite une vue "Profil", la vue appelle un créateur d'action profileRequest, le ApiUtils est appelé, certaines données arrivent, un ServerAction est créé, le ProfileStore se met à jour et le ProfileView le fait en conséquence.

Avec la mise en cache: le ProfileView demande au ProfileStore un certain profil, le magasin ne l'a pas, donc retourne un objet vide avec l'état 'loading', et appelle ApiUtils à récupérer ce profil (et l'oublier). Une fois l'appel terminé, un ServerAction sera créé, le ProfileStore se mettra à jour, etc. Cela fonctionne très bien. Vous pouvez également appeler et ActionCreator du magasin, mais je ne vois pas l'avantage.

MartyJS fait quelque chose de similaire. Certaines implémentations de flux font de même avec des promesses.

Je pense que la partie importante est: lorsque les données reviennent dans le système, un ServerActionCreator est appelé avec les nouvelles données. Cela retourne ensuite dans les magasins.

Je pense que les magasins ne devraient interroger que les données, toutes les actions de changement d'état (mise à jour) doivent être initiées par l'utilisateur (provenir des vues). Les ingénieurs de Facebook ont ​​écrit à ce sujet ici: https://news.ycombinator.com/item?id=7719957

  1. Existe-t-il une flèche virtuelle unilatérale se connectant du magasin aux créateurs d'action?

Si vous voulez que vos magasins soient intelligents: oui. Si vous voulez que votre application soit simple: non, passez par Vues.

  1. Quels sont les rappels entre Dispatcher et Store?

Ce sont les gestionnaires d'expédition que vous trouverez dans les magasins. Le répartiteur déclenche une action, stocke l'écoute de cet événement d'incendie et fait quelque chose avec l'action/la charge utile.

  1. Quelle est l'API Web ici? Est-ce là que vous appliqueriez une API RESTful? Y a-t-il un exemple de cela quelque part?

C'est là que vont vos appels ajax. En général, cela signifie une certaine REST, mais pourrait également être des sockets Web ou autre chose. J'ai toujours aimé ce tutoriel: http://fancypixel.github.io/blog/2015/01/29/react-plus-flux-back-by-Rails-api-part-2 /

Avertissements: ce sont mes interprétations de Flux. Le flux lui-même ne résout pas vraiment la récupération des données, c'est pourquoi ils ont trouvé Relay et GraphQL chez FB

5
RoryKoehein