Perché utilizzare un negozio per entità nell'architettura dell'applicazione di flusso?

Question

Sto usando reactjs e l'architettura di flusso in un progetto su cui sto lavorando. Sono un po 'perplesso su come suddividere correttamente i dati nidificati nei negozi e perché dovrei suddividere i miei dati in più negozi.

di spiegare il problema userò questo esempio:

immaginare un'applicazione Todo dove si hanno progetti. Ogni progetto ha compiti e ogni attività può avere note.

L'applicazione utilizza un API REST per recuperare i dati, restituendo la seguente risposta:

{ 
    projects: [ 
     { 
      id: 1, 
      name: "Action Required", 
      tasks: [ 
       { 
        id: 1, 
        name: "Go grocery shopping", 
        notes: [ 
         { 
          id: 1, 
          name: "Check shop 1" 
         }, 
         { 
          id: 2, 
          name: "Also check shop 2" 
         } 
        ] 
       } 
      ] 
     }, 
    ] 
} 

L'interfaccia dell'applicazione fittizia visualizza un elenco di progetti a sinistra e quando si seleziona un progetto, quel progetto diventa attivo e i suoi compiti sono visualizzati sulla destra. Quando fai clic su un'attività, puoi vederne le note in un popup.

Quello che vorrei fare è utilizzare 1 negozio singolo, il "Project Store". Un'azione esegue la richiesta al server, recupera i dati e ordina al negozio di riempirsi con i nuovi dati. Il negozio salva internamente questo albero di entità (Progetti -> Attività -> Note).

Per poter mostrare e nascondere le attività in base al progetto selezionato, manterrei anche una variabile nello store, "activeProjectId". In base a ciò la vista può ottenere il progetto attivo, i suoi compiti e renderli.

Problema risolto.

Tuttavia, dopo aver cercato un po 'online per vedere se questa è una buona soluzione, vedo un sacco di persone che affermano che è necessario utilizzare un negozio separato per entità.

Ciò significherebbe: A ProjectStore, TaskStore e NoteStore. Per essere in grado di gestire le associazioni, ho anche bisogno di un "TasksByProjectStore" e un "NotesByTaskStore".

Qualcuno può spiegare perché questo sarebbe meglio? L'unica cosa che vedo è un sovraccarico nella gestione degli archivi e del flusso di dati.

Answer 1

Ci sono pro e contro per utilizzare un negozio o diversi negozi. Alcune implementazioni di flusso favoriscono in modo specifico un negozio per dominarli tutti, per così dire, mentre altri facilitano anche più negozi.

Se un negozio o più negozi si adattano alle tue esigenze, dipende da a) cosa fa l'app, e b) quali sviluppi futuri o cambiamenti ti aspetti. In poche parole:

• Un negozio è meglio se la preoccupazione principale è le dipendenze tra le entità nidificate. E se sei meno preoccupato delle dipendenze tra la relazione singola entità tra il componente server-negozio. Un negozio è ottimo se ad es. vuoi gestire le statistiche a livello di progetto su attività e note sottostanti. Molte relazioni parent-child-like e server di recupero di dati all-in-one favoriscono una soluzione di archiviazione.
• Più negozi meglio se la vostra preoccupazione principale è la dipendenza tra le connessioni di entità singola tra server-negozio-componente. Debole relazioni entità-entità e fetch e aggiornamenti di singoli server indipendenti favoriscono più negozi.

Nel tuo caso: la mia scommessa sarebbe che un negozio è migliore.Hai una chiara relazione genitore-figlio e ricevi tutti i dati del progetto contemporaneamente dal server.

La risposta un po 'più a lungo:

Un negozio:

• Grande per ridurre al minimo sovraccarico di gestione di più negozi.
• Funziona bene se il componente della vista superiore è l'unico componente stateful e ottiene tutti i dati dallo store e distribuisce i dettagli ai bambini senza stato.
• Tuttavia, la necessità di gestire le dipendenze tra le entità non va semplicemente via: invece di gestirli tra diversi negozi, è necessario gestirli all'interno del singolo negozio. Che quindi diventa più grande (più linee di codice).
• Inoltre, in un tipico setup di flusso, ogni negozio emette un singolo evento "I have changed" e lo lascia al (i) componente (i) per capire cosa è cambiato e se hanno bisogno di ri-rendering top. Pertanto, se si dispone di numerose entità nidificate e una delle entità riceve molti aggiornamenti dal server, il proprio superstore emette molte modifiche, che potrebbero innescare molti aggiornamenti non necessari dell'intera struttura e di tutti i componenti. Flux-react può gestire molto, e il dettaglio-cambiato-update-tutto è quello che gestisce bene, ma potrebbe non soddisfare le esigenze di tutti (ho dovuto abbandonare questo approccio quando ha rovinato le mie transizioni tra stati in un progetto).

Più negozi:

• più in alto, sì, ma per alcuni progetti che ottenere rendimenti così
• se si dispone di uno stretto accoppiamento tra dati del server e componenti, con l'archivio di flusso in mezzo, è più facile separare le preoccupazioni nei negozi separati
• se ad es. ci si aspetta molte modifiche e aggiornamenti alla struttura dei dati delle note, che è più facile avere un componente stateful per le note, che ascolta l'archivio delle note, che a sua volta gestisce gli aggiornamenti dei dati delle note dal server. Durante l'elaborazione delle modifiche nella struttura delle note, è possibile concentrarsi solo sull'archivio delle note, senza capire come vengono gestite le note all'interno di un grande ipermercato.