Quelle est la différence entre thunk et saga dans le middleware React ?

La différence entre thunk et saga dans le middleware React : 1. [redux-thunk] ne prend en charge que les objets originaux [(plain object)] et gère les actions avec des effets secondaires 2. [redux-saga] gère tout pour ; opérations asynchrones, la partie interface asynchrone est claire en un coup d'œil.

L'environnement d'exploitation de ce tutoriel : système windows7, version React17 Cette méthode convient à toutes les marques d'ordinateurs.

Recommandations d'apprentissage associées : Tutoriel vidéo React

La différence entre thunk et saga dans le middleware React :

1. L'utilisation et les inconvénients de redux-thunk

(1) L'utilisation de redux-thunk

thunk est un middleware donné par l'auteur de redux. extrêmement simple à mettre en œuvre, avec plus de 10 lignes de code :

function createThunkMiddleware(extraArgument) {
  return ({ dispatch, getState }) => next => action => {
    if (typeof action === 'function') {
      return action(dispatch, getState, extraArgument);
    }
    return next(action);
  };
}
const thunk = createThunkMiddleware();
thunk.withExtraArgument = createThunkMiddleware;
export default thunk;

Ce que font ces lignes de code est également très simple. Identifiez le type d'action. Si l'action est une fonction, appelez cette fonction. les étapes sont :

action(dispatch, getState, extraArgument);

Découvrez le réel. Les paramètres sont dispatch et getState, donc lorsque nous définissons l'action comme une fonction thunk, les paramètres formels généraux sont dispatch et getState.

(2) Les lacunes de redux-thunk

Les défauts de thunk sont également évidents. Oui, thunk n'exécute que cette fonction et ne se soucie pas de ce qu'il y a dans le corps de la fonction. En d'autres termes, thunk permet à redux d'accepter des fonctions comme des actions, mais l'intérieur de la fonction peut être diversifié. Par exemple, ce qui suit est une opération asynchrone pour obtenir une liste de produits. Le magasin d'actions

correspondant introduit d'abord le middleware

import { createStore, applyMiddleware, compose } from 'redux';
import thunk from 'redux-thunk';
import rootReducer from './reducers/index';
const initialState = {};
const middleware = [thunk];
export const store = createStore(
rootReducer,
initialState,
compose(
applyMiddleware(...middleware),
Windows.__REDUX_DEVTOOLS_EXTENSION__ && Windows.__REDUX_DEVTOOLS_EXTENSION__()
)
);

dans le fichier d'action.

import { FETCH_POSTS, NEW_POST } from './type'
export const fetchPosts = () => dispatch => {
fetch("https://jsonplaceholder.typicode.com/posts")
        .then(res => res.JSON())
        .then(posts =>
        dispatch({
        type: FETCH_POSTS,
        payload: posts
        })
        )
}
export const createPost = postData => dispatch => {
fetch("https://jsonplaceholder.typicode.com/posts",{
        method: "POST",
        headers:{
            "content-type":"application/json"
        },
        body:JSON.stringify(postData)
    })
    .then(res => res.JSON())
    .then(post =>
    dispatch({
    type: NEW_POST,
    payload: post
    })
    )
}

. De cette action avec effets secondaires, nous pouvons voir que la fonction est extrêmement complexe à l'intérieur. Si vous devez définir une action comme celle-ci pour chaque opération asynchrone, il est évident que l'action n'est pas facile à maintenir. .

La raison pour laquelle l'action n'est pas facile à maintenir :

I) La forme de l'action n'est pas uniforme

II) est que les opérations asynchrones sont trop dispersées et dispersées. diverses actions

2. Utilisation de redux-saga

Dans redux-saga, l'action est un objet simple (objet d'origine) et gère de manière centralisée toutes les opérations asynchrones. l'exemple officiel de redux-saga shopping-cart comme exemple pour parler de l'utilisation de redux-saga

shopping-cartL'exemple est très simple, le processus suivant est montré :

. Liste des produits-->Ajouter un produit-->Panier-->Paiement

La page spécifique est la suivante :

Évidemment, il y a deux opérations asynchrones évidentes qui doivent être effectué ici :

Obtenir la liste des produits et le paiement

sont représentés par getAllProducts() et checkout() Si thunk est utilisé, alors ces deux opérations asynchrones appartiennent à deux actions différentes, mais dans. saga, ils sont traités de manière centralisée.

En utilisant saga, nous générons d'abord un fichier saga.JS qui traite le traitement asynchrone de manière centralisée :

import { put, takeEvery, call } from 'redux-saga/effects'
import { CHANGE_HITOKOTO_RESP, CHANGE_HITOKOTO } from '../actions/Hitokoto'
import hitokotoApi from '../services/hitokoto'
function gethitokoto() {
    return hitokotoApi.get().then(resp => resp)
}
export function* changeHitokoto() {
    const defaultHitokoto = {
        'id': 234,
        'hitokoto': '没有谁能够永远坚强下去的, 每个人都会有疲累的无法站起的时候. 世间的故事, 就是为了这一刻而存在的哦.',
        'type': 'a',
        'from': '文学少女',
        'creator': '酱七',
        'created_at': '1468605914'
    };
    try {
        const data = yield call(gethitokoto);
        const hitokotoData = JSON.parse(data);
        yield put({ type: CHANGE_HITOKOTO_RESP, hitokotoData });
    } catch (error) {
        yield put({ type: CHANGE_HITOKOTO_RESP, hitokotoData: defaultHitokoto });
    }
}
export default function* shici() {
    yield takeEvery(CHANGE_HITOKOTO, changeHitokoto)
}

Jetant les autres parties (l'utilisation spécifique sera expliquée plus tard) , on voit que ces deux opérations asynchrones getAllProducts() et checkout()

sont concentrées dans saga.JS De plus, l'action dans saga est différente de l'original Les objets sont exactement les mêmes. le créateur d'action dans la saga :

export const GET_ALL_PRODUCTS = 'GET_ALL_PRODUCTS'
export function getAllProducts() {
  return {
    type: GET_ALL_PRODUCTS,
  }
}

Dans le créateur d'action ci-dessus, l'action créée est un objet simple, ce qui est cohérent avec le style de synchronisation des actions que nous utilisons dans Redux.

Avantages et inconvénients de redux-saga

Avantages :

(1) Toutes les opérations asynchrones sont traitées de manière centralisée et la partie interface asynchrone est claire en un coup d'œil

(2) action C'est un objet ordinaire, qui est exactement la même que l'action de synchronisation redux

(3) Grâce à l'effet, il est pratique de tester l'interface asynchrone

(4) Grâce aux travailleurs et aux observateurs, non- le blocage des appels asynchrones peut être réalisé, et en même temps la surveillance des événements sous les appels non bloquants peut être réalisée

(5) Le processus des opérations asynchrones peut être contrôlé et les opérations asynchrones correspondantes peuvent être annulées à tout moment temps.

Inconvénients : Trop compliqué, coût d'apprentissage élevé

Recommandations d'apprentissage associées : Tutoriel d'apprentissage javascript

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!