Pourquoi utiliser redux-thunk ou redux-saga pour les récupérations ?

Question

Je continue à lire que je devrais utiliser redux-thunk ou redux-saga pour gérer les effets secondaires. Pourquoi ne pas simplement utiliser des créateurs d'actions comme ceux-là pour distribuer plusieurs actions :

function loadProductActionCreator(dispatch) {
  dispatch({
    type: 'load_product',
  })
  fetch('api/product').then(
    function (r) {
      return r.json();
    }
  )
  .then(function (res) {
    dispatch({
      type: 'loaded_product',
      data: res
    })
  })
}

J'ai essayé et ça a marché ( code complet ). Je suppose donc qu'il doit y avoir des inconvénients dont je ne suis pas conscient.

Answer 1

Votre code est similaire à ce que fait Thunk.

Conformément à redux docs, les actions doivent être pures. Et elles doivent toujours retourner les mêmes valeurs pour les mêmes paramètres d'entrée. En utilisant fetch vous permettez à l'action de retourner non pas une valeur spécifique, mais une valeur du serveur, ce qui signifie que la réponse de l'action peut varier dans le temps.

Cela s'appelle effets secondaires . Et c'est quelque chose qui ne devrait pas être dans les actions redux par défaut.

Mais pourquoi ?

Oui, vous pouvez le taper dans l'action comme vous l'avez fait, dans les petites applications, cela n'a pas d'importance.

Dans les applications plus importantes, il y a des avantages à utiliser redux-saga :

• sont prévisibles, elles renvoient simplement des données utiles comme

  {
    type: 'FETCH_POSTS',
    params: {
      category: 'programming'
    }
  }

• et ensuite vous construisez un intergiciel qui prendra des mesures avec toutes les données requises pour effectuer une demande à l'API réelle.

Avantages possibles :

• Base de code plus propre (mais peut représenter une surcharge pour les petites applications).
• Séparation des actions "factices" contenant toutes les informations nécessaires à l'exécution des requêtes et du véritable middleware API.
• Les paramètres des requêtes sont visibles directement dans les outils de développement redux.
• Il est possible d'obtenir facilement debounce , throttle les recherches qui peuvent être très délicates avec redux-thunk
• Possibilité de combiner facilement des actions (attendre un autre événement/récupérer, enchaîner des événements)
• Possibilité d'arrêter les tâches en cours

D'après mon expérience personnelle, sur un projet (base de code plus importante) nous avons commencé par redux-thunk Mais par la suite, nous avons dû intégrer des fonctions plus avancées, comme l'accélérateur, et certaines dépendances entre les actions. Nous avons donc tout réécrit en redux-saga et ça a bien marché pour nous.

Answer 2

Vous reproduisez en quelque sorte le redux-thunk ici. Un pur créateur d'action redux devrait renvoyer un objet d'action à distribuer et non pas distribuer une action elle-même (cf. doc redux sur le créateur d'actions ).

Pour mieux comprendre pourquoi votre technique est une réplication de redux-thunk, regardez ce poste de son auteur