Pourquoi utiliser un middleware pour les actions asynchrones dans Redux ?

Pourquoi avons-nous besoin d'un middleware pour le flux de données asynchrone dans Redux ?

Il peut sembler au départ que Redux ne prend pas en charge le flux de données asynchrone puisqu'il spécifie que "le magasin Redux ne prend en charge que le flux de données synchrone". Cependant, ce n'est pas le cas.

Dans l'exemple donné, le composant conteneur peut certainement invoquer l'API asynchrone et ensuite envoyer les actions nécessaires. En fait, cette approche fonctionne correctement, comme le démontre la mise à jour du champ lorsque le bouton est cliqué.

Quel est alors le problème avec cette stratégie ?

Le la principale préoccupation se pose dans le contexte d'une application plus vaste où de nombreux composants peuvent effectuer des actions identiques ou où il peut être souhaitable d'incorporer des fonctionnalités telles que l'anti-rebond. De plus, il peut être avantageux de préserver l'état local des créateurs d'actions proches pour des tâches telles que l'incrémentation automatique des identifiants.

Du point de vue de la maintenance, cela simplifie les choses en séparant les créateurs d'actions en fonctions distinctes, simplifiant ainsi le développement et la maintenance du codebase.

Bien que les middlewares comme Redux Thunk ou Redux Promise fournissent une simplification du code grâce au sucre syntaxique, cela n'est pas strictement nécessaire à des fins de gestion actions asynchrones.

Sans Middleware :

En l'absence de middleware, les créateurs d'actions peuvent effectuer des opérations asynchrones directement, comme illustré ci-dessous :

function loadData(dispatch, userId) {
  fetch(`http://data.com/${userId}`)
    .then(res => res.json())
    .then(
      data => dispatch({ type: 'LOAD_DATA_SUCCESS', data }),
      err => dispatch({ type: 'LOAD_DATA_FAILURE', err })
    );
}

// in component
componentWillMount() {
  loadData(this.props.dispatch, this.props.userId); // pass dispatch as argument for async action creator
}

Avec Thunk Middleware :

Redux Thunk propose une syntaxe plus concise pour la répartition des actions asynchrones :

function loadData(userId) {
  return dispatch =>
    fetch(`http://data.com/${userId}`)
      .then(res => res.json())
      .then(
        data => dispatch({ type: 'LOAD_DATA_SUCCESS', data }),
        err => dispatch({ type: 'LOAD_DATA_FAILURE', err })
      );
}

// in component
componentWillMount() {
  this.props.dispatch(loadData(this.props.userId)); // dispatch as usual
}

Avantages du middleware :

Les principaux avantages de l'utilisation d'un middleware comme Redux Thunk résident dans le découplage des composants des détails d'implémentation du créateur d'action . Les composants ne savent pas si un créateur d'action est synchrone ou asynchrone et s'il interagit avec l'état Redux ou d'autres créateurs d'action.

Alternatives au middleware :

Redux Thunk est ce n'est pas la seule approche pour gérer les requêtes asynchrones dans les applications Redux. Une autre alternative intéressante est Redux Saga, qui permet de définir des « sagas » de longue durée qui opèrent sur les actions entrantes, transformant ou exécutant des requêtes avant de produire d'autres actions.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!