React-Redux: tutti gli stati dei componenti devono essere mantenuti in Redux Store

Diciamo che ho un semplice interruttore:

Quando faccio clic sul pulsante, il componente Colore cambia tra rosso e blu

Potrei ottenere questo risultato facendo qualcosa di simile.

index.js

Button: onClick={()=>{dispatch(changeColor())}}
Color: this.props.color ? blue : red

container.js

connect(mapStateToProps)(indexPage)

action_creator.js

function changeColor(){
 return {type: 'CHANGE_COLOR'}
}

riduttore.js

switch(){
case 'CHANGE_COLOR':
return {color: true}

ma questo è un sacco di codice da scrivere per qualcosa che avrei potuto ottenere in 5 secondi con jQuery, alcune classi e alcuni css ...

Quindi immagino che quello che sto chiedendo davvero sia, cosa sto facendo di sbagliato qui?

Redux è destinato principalmente allo "stato dell'applicazione". Cioè, tutto ciò che riguarda la logica dell'applicazione. La vista costruita sopra è un riflesso di quello stato, ma non deve utilizzare esclusivamente quel contenitore di stato per tutto ciò che fa.

Poni semplicemente queste domande: questo stato è importante per il resto dell'applicazione? Altre parti dell'applicazione si comporteranno diversamente in base a quello stato? In molti casi minori, non sarà così. Prendi un menu a discesa: il fatto che sia aperto o chiuso probabilmente non avrà alcun effetto su altre parti dell'app. Quindi, collegarlo al tuo negozio è probabilmente eccessivo. È certamente un'opzione valida, ma non ti procura alcun vantaggio. È meglio usarlo this.statee chiamarlo un giorno.

Nel tuo esempio particolare, il colore di quel pulsante è attivato per fare la differenza in altre parti dell'applicazione? Se è una sorta di attivazione / disattivazione globale per una parte importante della tua applicazione, appartiene sicuramente allo store. Ma se stai solo cambiando il colore di un pulsante quando fai clic sul pulsante, puoi lasciare lo stato del colore definito localmente. L'azione di fare clic sul pulsante potrebbe avere altri effetti che richiedono l'invio di un'azione, ma questo è separato dalla semplice domanda di quale colore dovrebbe essere.

In generale, cerca di mantenere lo stato dell'applicazione il più piccolo possibile. Non devi spingere tutto lì dentro. Fallo quando devi o ha molto senso tenere qualcosa lì. O se ti semplifica la vita quando usi Dev Tools. Ma non sovraccaricare troppo la sua importanza.

Domande frequenti su Redux: Organizzare
questa parte del documento ufficiale di redux ha risposto bene alla tua domanda.

L'uso dello stato del componente locale va bene . In qualità di sviluppatore, è tuo compito determinare quali tipi di stato costituiscono la tua applicazione e dove dovrebbe risiedere ogni parte di stato. Trova un equilibrio che funzioni per te e seguilo.

Alcune regole pratiche comuni per determinare il tipo di dati da inserire in Redux:

• Altre parti dell'applicazione si preoccupano di questi dati?
• Hai bisogno di essere in grado di creare ulteriori dati derivati ​​basati su questi dati originali?
• Gli stessi dati vengono utilizzati per guidare più componenti?
• C'è valore per te nell'essere in grado di ripristinare questo stato a un dato punto nel tempo (cioè, il debug del viaggio nel tempo)?
• Vuoi memorizzare nella cache i dati (ad esempio, utilizzare ciò che è nello stato se è già presente invece di richiederlo nuovamente)?

Allo scopo di evidenziare l'ottimo collegamento fornito da @ AR7 e poiché quel collegamento è stato spostato un po 'indietro:

Usa React per uno stato effimero che non ha importanza per l'app a livello globale e non muta in modi complessi. Ad esempio, un interruttore in un elemento dell'interfaccia utente, uno stato di input del modulo. Usa Redux per lo stato che conta a livello globale o è mutato in modi complessi. Ad esempio, utenti memorizzati nella cache o una bozza di post.

A volte potresti voler passare dallo stato Redux allo stato React (quando memorizzare qualcosa in Redux diventa scomodo) o viceversa (quando più componenti devono avere accesso a uno stato che era locale).

La regola pratica è: fai ciò che è meno imbarazzante.

Dan Abramov: https://github.com/reactjs/redux/issues/1287#issuecomment-175351978

Sì, vale la pena sforzarsi di memorizzare tutto lo stato dei componenti in Redux . Se lo fai, trarrai vantaggio da molte funzionalità di Redux come il debug del viaggio nel tempo e le segnalazioni di bug riproducibili. In caso contrario, queste funzionalità potrebbero essere completamente inutilizzabili .

Ogni volta che non si memorizza una modifica dello stato di un componente in Redux, tale modifica viene completamente persa dallo stack di modifiche Redux e l'interfaccia utente dell'applicazione non sarà sincronizzata con lo store. Se questo non è importante per te, chiediti perché usare Redux? La tua applicazione sarà meno complessa senza di essa!

Per motivi di prestazioni, potresti voler ricorrere a this.setState()tutto ciò che potrebbe inviare molte azioni ripetutamente. Ad esempio: memorizzare lo stato di un campo di input in Redux ogni volta che l'utente digita una chiave può comportare prestazioni scadenti. Puoi risolvere questo problema trattandolo come una transazione: una volta che l'azione dell'utente è stata "confermata", salva lo stato finale in Redux.

Il tuo post originale menziona come il metodo Redux sia "un sacco di codice da scrivere". Sì, ma puoi usare astrazioni per modelli comuni come lo stato del componente locale.