React Context vs React Redux, quando dovrei usarli tutti? [chiuso]

React 16.3.0 è stato rilasciato e l' API di contesto non è più una funzionalità sperimentale. Dan Abramov (il creatore di Redux) ha scritto qui un buon commento su questo, ma erano 2 anni che il contesto era ancora una caratteristica sperimentale.

La mia domanda è, secondo la tua opinione / esperienza, quando dovrei usare React Context su React Redux e viceversa?

Dato che il contesto non è più una funzionalità sperimentale e puoi utilizzare direttamente il contesto nella tua applicazione e sarà ottimo per trasmettere i dati a componenti profondamente nidificati per i quali è stato progettato.

Come ha scritto Mark erikson nel suo blog :

Se stai usando Redux solo per evitare di tramandare oggetti di scena, il contesto potrebbe sostituire Redux, ma probabilmente non hai bisogno di Redux in primo luogo.

Il contesto inoltre non offre nulla di simile Redux DevTools, la possibilità di tracciare gli aggiornamenti di stato, middlewareaggiungere logica applicativa centralizzata e altre potenti funzionalità che Redux consentono.

Reduxè molto più potente e offre un gran numero di funzionalità che Context Apinon forniscono, anche come citato da As @danAbramov

React Redux utilizza il contesto internamente ma non espone questo fatto nell'API pubblica. Quindi dovresti sentirti molto più sicuro usando il contesto tramite React Redux che direttamente perché se cambia, l'onere dell'aggiornamento del codice sarà su React Redux e non tu.

Spetta a Redux aggiornare effettivamente la sua implementazione per aderire all'ultima API di contesto

L'API di contesto più recente può essere utilizzata per le applicazioni in cui si utilizzerà semplicemente Redux per passare i dati tra i componenti, tuttavia l'applicazione che utilizza dati centralizzati e gestisce le richieste API nei creatori di azioni che utilizzano redux-thunko redux-saganecessiterebbe comunque di redux. Oltre a questo redux sono associate altre librerie come quelle redux-persistche ti permettono di salvare i dati del negozio in localStorage e reidratarti all'aggiornamento, che è ciò che l'API di contesto non supporta ancora.

Come ha detto @dan_abramov nel suo blog Potresti non aver bisogno di Redux , che redux ha un'applicazione utile come

• Persistere lo stato su un archivio locale e quindi avviare da esso, immediatamente.
• Pre-riempire lo stato sul server, inviarlo al client in HTML e avviarlo da lì, immediatamente.
• Serializzare le azioni dell'utente e allegarle, insieme a un'istantanea dello stato, alle segnalazioni automatiche di bug, in modo che gli sviluppatori del prodotto
  possano riprodurle per riprodurre gli errori.
• Passa gli oggetti azione sulla rete per implementare ambienti collaborativi senza cambiamenti drammatici nella modalità di scrittura del codice.
• Mantieni una cronologia degli annullamenti o implementa mutazioni ottimistiche senza cambiamenti drammatici nella modalità di scrittura del codice.
• Viaggia tra la storia dello stato in fase di sviluppo e rivaluta lo stato corrente dalla storia dell'azione quando il codice cambia, alla TDD.
• Fornire funzionalità complete di ispezione e controllo agli strumenti di sviluppo in modo che gli sviluppatori di prodotti possano creare strumenti personalizzati per le loro
  app.
• Fornire interfacce utente alternative riutilizzando la maggior parte della logica aziendale.

Con queste numerose applicazioni è troppo presto per dire che Redux sarà sostituito dalla nuova API di contesto

Se stai usando Redux solo per evitare di passare oggetti di scena a componenti profondamente nidificati , puoi sostituire Redux con l' ContextAPI. È esattamente destinato a questo caso d'uso.

D'altra parte, se stai usando Redux per tutto il resto (avendo un contenitore di stato prevedibile, gestendo la logica della tua applicazione al di fuori dei tuoi componenti, centralizzando lo stato della tua applicazione, usando Redux DevTools per tracciare quando, dove, perché e come lo stato della tua applicazione modificato o utilizzando plugin come Redux Form , Redux Saga , Redux Undo , Redux Persist , Redux Logger , ecc ...), quindi non c'è assolutamente alcun motivo per cui abbandoni Redux. L' ContextAPI non fornisce nulla di tutto ciò.

E personalmente ritengo che l'estensione RedTool DevTools sia uno strumento di debug sorprendente e sottovalutato, che giustifica da solo per continuare a utilizzare Redux.

Alcuni riferimenti:

• Redux non è ancora morto!
• Potrebbe non essere necessario Redux
• I ganci React sostituiscono Redux?

Preferisco usare redux con redux-thunk per effettuare chiamate API (anche usando Axios) e inviare la risposta ai riduttori. È pulito e facile da capire.

L'API di contesto è molto specifica per la parte di reazione-redux su come i componenti di React sono collegati al negozio. Per questo, il reagente reattivo è buono. Ma se lo desideri, poiché il contesto è ufficialmente supportato, puoi utilizzare l'API di contesto invece di reagire-redux.

Pertanto, la domanda dovrebbe essere l'API di contesto vs reagire-redux e non l'API di contesto vs redux. Inoltre, la domanda è leggermente supponente. Da allora, ho familiarità con il reagente a reazione e lo uso in tutti i progetti, continuerò a usarlo. (Non c'è alcun incentivo per me a cambiare).

Ma se stai imparando il redux proprio oggi, e non l'hai usato da nessuna parte, vale la pena dare un colpo all'API di contesto e sostituire il reagente-redux con il tuo codice dell'API di contesto personalizzato. Forse è molto più pulito in quel modo.

Personalmente, è una questione di familiarità. Non esiste un motivo chiaro per scegliere l'uno rispetto all'altro perché sono equivalenti. E internamente, reattivo-redux utilizza comunque il contesto.

Le uniche ragioni per usare Redux per me sono:

• Vuoi un oggetto stato globale (per vari motivi, come debuggabilità, persistenza ...)
• La tua app è o sarà grande e dovrebbe ridimensionarsi a molti sviluppatori: in tal caso probabilmente avrai bisogno di un livello di riferimento indiretto (ovvero un sistema di eventi): spari eventi (in passato) e quindi persone che non conosci nel tuo l'organizzazione può effettivamente ascoltarli

Probabilmente non è necessario il livello di riferimento indiretto per l'intera app, quindi va bene mescolare stili e utilizzare lo stato / contesto locale e Redux entrambi allo stesso tempo.

• Se è necessario utilizzare il middleware per vari scopi. Ad esempio azioni di registrazione, segnalazione errori, invio di altre richieste in base alla risposta del server, ecc.
• Quando i dati provenienti da più endpoint influenzano il singolo componente / vista.
• Quando vuoi avere un maggiore controllo sulle azioni nelle tue applicazioni. Redux consente azioni di tracciamento e modifica dei dati, semplifica notevolmente il debug.
• Se non si desidera che la risposta del server cambi direttamente lo stato dell'applicazione. Redux aggiunge un livello, in cui puoi decidere come, quando e se applicare questi dati. Il modello di osservatore. Invece di creare più editori e abbonati nell'intera app, basta connettere i componenti al negozio Redux.

Da: quando usare Redux?