Come nota: ho letto i documenti per Redux (anche Baobab) e ho fatto una buona parte di Google e test.
Perché è così fortemente suggerito che un'app Redux abbia un solo negozio?
Comprendo i pro / contro di una configurazione a negozio singolo rispetto a una configurazione a negozio multiplo ( ci sono molte domande e risposte su SO su questo argomento ).
IMO, questa decisione architettonica appartiene agli sviluppatori di app in base alle esigenze dei loro progetti. Allora perché è così fortemente suggerito per Redux, quasi al punto di sembrare obbligatorio ( anche se nulla ci impedisce di creare più negozi )?
EDIT: feedback dopo la conversione in negozio singolo
Dopo alcuni mesi di lavoro con Redux su ciò che molti considererebbero una SPA complessa, posso dire che la struttura del singolo negozio è stata una vera delizia con cui lavorare.
Alcuni punti che potrebbero aiutare gli altri a capire perché un singolo negozio contro molti negozi è una domanda controversa in molti, molti casi d'uso:
- è affidabile : utilizziamo i selettori per esaminare lo stato dell'app e ottenere informazioni pertinenti al contesto. Sappiamo che tutti i dati necessari si trovano in un unico negozio. Evita ogni dubbio su dove potrebbero essere i problemi di stato.
- è veloce : il nostro negozio ha attualmente quasi 100 riduttori, se non di più. Anche a quel punto, solo una manciata di riduttori elabora i dati su una determinata spedizione, gli altri restituiscono semplicemente lo stato precedente. L'argomento secondo cui un negozio enorme / complesso (numero di riduttori ) è lento è praticamente discutibile. Almeno non abbiamo visto alcun problema di prestazioni proveniente da lì.
- debugging amichevole : mentre questo è un argomento molto convincente per usare il redux nel suo insieme, vale anche per un singolo negozio contro più negozi. Quando si crea un'app, si è tenuti ad avere errori di stato nel processo ( errori del programmatore ), è normale. Il PITA è quando quegli errori impiegano ore per il debug. Grazie al singolo negozio ( e redux-logger ) non abbiamo mai trascorso più di qualche minuto su un dato problema di stato.
alcuni suggerimenti
La vera sfida nella costruzione del tuo negozio redux è quando decidi come strutturarlo . Innanzitutto, perché cambiare la struttura lungo la strada è solo un grande dolore. In secondo luogo, perché determina in gran parte il modo in cui verrà utilizzato e l'interrogazione dei dati dell'app per qualsiasi processo. Ci sono molti suggerimenti su come strutturare un negozio. Nel nostro caso abbiamo trovato quanto segue ideale:
{
apis: { // data from various services
api1: {},
api2: {},
...
},
components: {} // UI state data for each widget, component, you name it
session: {} // session-specific information
}
Spero che questo feedback possa aiutare gli altri.
EDIT 2 - utili strumenti di archiviazione
Per quelli di voi che si sono chiesti come "gestire" facilmente un singolo negozio , che può diventare rapidamente complesso. Esistono strumenti che aiutano a isolare le dipendenze strutturali / la logica del tuo negozio.
C'è Normalizr che normalizza i tuoi dati in base a uno schema. Fornisce quindi un'interfaccia per lavorare con i tuoi dati e recuperare altre parti dei tuoi dati id
, proprio come un dizionario.
Non sapendo Normalizr al momento, ho costruito qualcosa seguendo le stesse linee. relational-json accetta uno schema e restituisce un'interfaccia basata su tabella ( un po 'come un database ). Il vantaggio di relational-json è che la struttura dei dati fa riferimento dinamicamente ad altre parti dei dati (in sostanza, è possibile attraversare i dati in qualsiasi direzione, proprio come i normali oggetti JS ). Non è maturo come Normalizr, ma lo uso con successo nella produzione da alcuni mesi.