Qual è la differenza tra redux-thunk e redux-promise?

Per quanto ne so e mi correggo se sbaglio, redux-thunk è un middleware che ci aiuta a inviare funzioni asincrone e valori di debug nell'azione stessa mentre quando ho usato redux-promise non potevo creare funzioni asincrone senza implementare le mie meccanismo come Action genera un'eccezione per l'invio di soli oggetti semplici.

Quali sono le principali differenze tra questi due pacchetti? Ci sono vantaggi nell'usare entrambi i pacchetti in un'unica app di reazione a pagina o sarebbe sufficiente attenersi a redux-thunk?

redux-thunk consente ai creatori di azioni di restituire una funzione:

function myAction(payload){
    return function(dispatch){
        // use dispatch as you please
    }
}

redux-promise consente loro di restituire una promessa:

function myAction(payload){
    return new Promise(function(resolve, reject){
        resolve(someData); // redux-promise will dispatch someData
    });
}

Entrambe le librerie sono utili se è necessario inviare l'azione in modo asincrono o condizionale. redux-thunkti consente anche di inviare più volte all'interno di un creatore di azioni. Che tu scelga uno, l'altro o entrambi dipende interamente dalle tue esigenze / stile.

Probabilmente vorrai / avrai bisogno di entrambi insieme nella tua app. Inizia con la redux-promise per le attività asincrone che generano promesse di routine e poi scala per aggiungere Thunk (o Sagas, ecc.) Man mano che la complessità aumenta :

• Quando la vita è semplice e stai solo facendo un lavoro asincrono di base con i creatori che restituiscono una singola promessa, allora redux-promise migliorerai la tua vita e lo semplificherai, veloce e facile. (In poche parole, invece di dover pensare a 'scartare' le tue promesse quando si risolvono, quindi scrivere / inviare i risultati, redux-promise (-middleware) si prende cura di tutte quelle cose noiose per te.)
• Ma la vita diventa più complessa quando:
  • Forse il tuo creatore di azioni vuole produrre diverse promesse, che vuoi inviare come azioni separate a riduttori separati?
  • Oppure hai una complessa pre-elaborazione e logica condizionale da gestire, prima di decidere come e dove inviare i risultati?

In questi casi, il vantaggio di redux-thunkè che ti consente di incapsulare la complessità all'interno del tuo creatore di azioni .

Ma tieni presente che se il tuo Thunk produce e invia promesse, allora ti consigliamo di utilizzare entrambe le librerie insieme :

• il Thunk componeva le azioni originali e le inviava
• redux-promisegestirà quindi lo scartamento presso i riduttori delle singole promesse generate dal tuo Thunk, per evitare il boilerplate che comporta. (Si potrebbe invece fare tutto quanto in thunk, con promise.then(unwrapAndDispatchResult).catch(unwrapAndDispatchError)... Ma perché si?)

Un altro modo semplice per riassumere la differenza nei casi d'uso: l'inizio e la fine del ciclo d'azione di Redux :

• I thunk sono per l' inizio del flusso Redux: se hai bisogno di creare un'azione complessa, o incapsulare una logica di creazione di azioni nodosa, tenendola fuori dai tuoi componenti e sicuramente fuori dai riduttori.
• redux-promiseè per la fine del tuo flusso, una volta che tutto è stato ridotto a semplici promesse, e vuoi solo scartarle e memorizzare il loro valore risolto / rifiutato nel negozio

  ---

NOTE / RISPOSTE:

• Trovo redux-promise-middlewareche sia un'implementazione più completa e comprensibile dell'idea alla base dell'originale redux-promise. È in fase di sviluppo attivo ed è anche ben integrato da redux-promise-reducer.
• ci sono altri middleware simili disponibili per comporre / sequenziare le tue azioni complesse: uno molto popolare è redux-saga, che è molto simile a redux-thunk, ma si basa sulla sintassi delle funzioni del generatore. Di nuovo, probabilmente lo useresti insieme a redux-promise.
• Ecco un ottimo articolo che confronta direttamente varie opzioni di composizione asincrona, inclusi thunk e redux-promise-middleware. (TL; DR: "Redux Promise Middleware riduce il boilerplate in modo abbastanza drammatico rispetto ad alcune delle altre opzioni" ... "Penso che mi piaccia Saga per applicazioni più complesse (leggi:" utilizza ") e Redux Promise Middleware per tutto il resto." )
• Nota che c'è un caso importante in cui potresti pensare di dover inviare più azioni, ma in realtà non lo fai e puoi mantenere semplici le cose semplici. È lì che vuoi solo che più riduttori reagiscano alla tua chiamata asincrona. Ma non c'è alcun motivo per cui più riduttori non possano monitorare un singolo tipo di azione. Dovresti semplicemente assicurarti che il tuo team sappia che stai usando quella convenzione, in modo che non presumano che solo un singolo riduttore (con un nome correlato) possa gestire una determinata azione.

Divulgazione completa: sono relativamente nuovo nello sviluppo di Redux e ho lottato con questa domanda da solo. Parafraserò la risposta più succinta che ho trovato:

ReduxPromise restituisce una promessa come payload quando viene inviata un'azione, quindi il middleware ReduxPromise lavora per risolvere quella promessa e passare il risultato al riduttore.

ReduxThunk, d'altra parte, costringe il creatore dell'azione a trattenere l'invio effettivo dell'oggetto azione ai riduttori finché non viene chiamato l'invio.

Ecco un collegamento al tutorial in cui ho trovato queste informazioni: https://blog.tighten.co/react-101-part-4-firebase .