Redux Saga async/await modèle

Je suis en utilisant async/await tout au long de ma base de code. De ce fait mes appels de l'api sont définies par async fonctions

async function apiFetchFoo {
  return await apiCall(...);
}

Je voudrais appeler cette fonction à partir de ma saga code. Il me semble que je ne peut pas faire cela:

//Doesn't work
function* fetchFoo(action) {
  const results = await apiFetchFoo();
  yield put({type: "FOOS_FETCHED_SUCCESSFULLY", foos: results});
}

Toutefois, cela fonctionne, et correspond à la redux saga de la documentation:

//Does work
function* fetchFoo(action) {
  const results = yield call(apiFetchFoo);
  yield put({type: "FOOS_FETCHED_SUCCESSFULLY", foos: results});
}

Est-ce la bonne façon d'utiliser les Redux Saga côtés async/await? Il est standard pour utiliser ce générateur de la syntaxe à l'intérieur de la saga de code, et la async/await modèle d'ailleurs?

  • Curieux, dans async/await motif pourquoi êtes-vous à l'aide de function *() { ... await } au lieu de async function () { .. await ...}? Je suis assez sûr que si vous utilisez attendent sans async elle conduit à une erreur "en attente est réservé javascript mot-clé".
InformationsquelleAutor mattnedrich | 2017-04-17
  1. 27

    Oui, c'est la manière standard d'utilisation Redux-Saga.

    Vous ne devriez jamais appeler la await fonction directement à l'intérieur de la saga-générateur, parce que redux-saga est pour l'orchestration de les effets secondaires. Par conséquent, chaque fois que vous voulez exécuter un des effets secondaires que vous devriez le faire en produisant les effets secondaires par l'intermédiaire d'un redux-saga effet (généralement: call ou fork). Si vous le faites directement, sans céder à travers un redux-saga effet, alors redux-saga ne sera pas en mesure d'orchestrer les effets secondaires.

    Si vous pensez à ce sujet, le redux-saga générateur est complètement testable sans la nécessité de se moquer de quelque chose. Cela aide aussi à garder les choses découplé: si votre apiFetchFoo retourné une promesse, la saga aurait toujours fonctionner de la même.

    • Vous pouvez inclure des liens vers de la documentation ou github questions où cela est discuté? Que faire si il y avait une situation où l'OP voulait await une Promesse qui n'a eu aucun des effets secondaires? Il me semble qu'il serait valable de cas d'utilisation de générateurs asynchrones, mais il ne semble pas comme Redux-Saga permet pour eux.
    • bien sûr! redux-saga.js.org je crains que vous ne comprenez pas bien ce que redux-saga est sur. Un redux-saga générateur est conçu pour orchestrer des effets secondaires. Si vous voulez faire quelque chose comme ce que vous mentionner, alors vous ne devriez pas le faire dans un redux-saga générateur... Vous pourriez le faire dans des conditions normales générateur -si vous voulez - ou dans une autre promesse, il n'a pas d'importance... et puis il suffit de donner un call effet à l'intérieur de la redux-saga générateur qui appelle cette promesse/générateur/whatever.
    • Ah oui, ça a du sens! Je pense que j'ai été mal à comprendre les limites d'un redux-saga générateur, et a été d'essayer d'en faire plus qu'il ne le devrait. Au lieu de cela, je doit attendre le "pas de côté-effet" la promesse de l'entité qui est donné dans la saga du générateur.
    • Juste pour la référence (peuvent aider les autres), voici une bonne explication de react-saga documentation de pourquoi il ne faut pas invoquer asynchrone fonctions directement dans la saga: redux-saga.js.org/docs/basics/DeclarativeEffects.html. Conformément à cette documentation, saga devrait produire des effets de la saga de middleware et de la saga de middleware d'exécuter la vigueur et la main sur le résultat de la saga. Les effets sont simples objets JS dire, de middleware, de quoi faire. Toute cette idée de donner des effets à la saga middleware de faire des tests unitaires de la saga simple, sans se moquant async des choses comme les appels d'API.
    InformationsquelleAutor Josep
  2. 0

    await toujours travailler au sein d'une fonction qui est déclaré comme async. #thumbRule

    async function fetchList () {
  let resp = await fetchApi([params]);
}
    InformationsquelleAutor Venkat
  3. 0

    Comme l'a souligné Josep, await ne peut pas être utilisé à l'intérieur d'un générateur. Au lieu de cela, vous devez utiliser un fonction async. Aussi, remarque c'est une limitation de l'asynchrone en fonction de lui-même. Il n'est pas imposé par redux-saga.

    Au-delà de cela, je voulais aussi mentionner que c'est une choix conscient par le redux-saga auteurs de pas permettre devs pour exprimer des sagas comme async/await fonctions.

    Générateurs sont plus puissants que les async/await et ils permettent à des fonctionnalités avancées de redux-saga comme co-coordination de tâches en parallèle.

    En outre, exprimant des sagas comme les générateurs de nous aider à définir Effets qui sont de simples objets de la définition de l'effet indésirable. Effets rend très facile de tester nos sagas.

    Ainsi, bien que votre code de travail est bien, peut-être de ne pas mélanger les sagas et de la fonction async est une bonne idée.

    Il suffit de définir votre apiFetchFoo de retour d'une promesse qui se résout avec la réponse à la demande. Et quand cela arrive, votre saga reprend avec le results.

     const apiFetchFoo = () =>
   fetch('foo')
     .then(res => res.json())
    InformationsquelleAutor Arijit Bhattacharya