Architettura redux/ngrx/store: perché non inviare azioni da componenti stupidi?

Question

Sto costruendo un'applicazione Angular 2 ngrx/store e sto cercando di capire le migliori pratiche.

• Mi piace avere uno stato immutabile che cambia solo in base alle azioni inviate in modo che lo stato dell'app sia molto chiaro e debug -abile.
• Amo il flusso di dati a una via verso il basso da contenitori "intelligenti" poiché questo ci consente di utilizzare il tubo asincrono per eseguire meno controlli di stato.

Ma non capisco perché vorremmo "bollare" gli eventi da componenti stupidi fino a componenti intelligenti prima di inviare un'azione al negozio. È l'unica ragione per avere componenti riutilizzabili? Mi sembra che la maggior parte dei componenti non vengano comunque riutilizzati perché non ci sono molte situazioni in cui vorrei avere tutto identico incluso il CSS. Ci sono altri benefici che mi mancano? Dal punto di vista della manutenibilità/leggibilità, non è più bello essere in grado di vedere solo l'azione inviata proprio al componente in cui sta avvenendo l'interazione?

Answer 1

Sono totalmente d'accordo con te e ho lo stesso dubbio.

Mi aspetto che il componente emetta un'azione utilizzando il dispatcher (che per ngrx/store è lo stesso negozio) invece di spostare questa logica nel contenitore (l'applicazione effettiva).

In questo modo il componente viene disaccoppiato dal contenitore e il contenitore non ha bisogno di essere informato sulle azioni: ascolterà solo il cambiamento di stato e trasmetterà gli eventuali dati, se necessario.

D'altra parte, lo Introduction to ngrx/store sta promuovendo il design con un contenitore più intelligente, che conosce molto sui componenti sottostanti.

Francamente, Non posso ancora vedere un chiaro vincitore: Penso solo che le azioni di dispacciamento dal componente è più semplice, più pulito e più vicino al Elm Architecture che era una delle ispirazioni del Redux.

Answer 2

Non ho trovato alcun riferimento sugli eventi "bubble up" ai componenti principali in ngrx/example-app. Anche nei discorsi di Rob non l'ho capito (forse mi sono perso qualcosa).

Sto solo utilizzando tutto il ngrx come nell'esempio e in questo momento sembra soddisfacente. ngrx/store per archiviare dati, ngrx/effetti in azioni concatenate (come posso semplificare) e "middleware" nell'immagine di "azioni" che descrivono tutto ciò che si è in grado di fare con una parte del negozio.

E poi quando sembra il più conveniente sto usando l'azione (mi sto solo assicurando che tutte le azioni utilizzate nel file siano rilevanti per la classe corrente).

Answer 3

Uno dei motivi principali è il riutilizzo.

In termini di MVC, pensa al tuo componente intelligente come controller e al tuo componente stupido come la tua vista.

Immagina un componente stupido che esegue il rendering di un modulo di modifica per una delle entità (modello). Il componente stupido gestisce la visualizzazione dei messaggi di form e validation, tuttavia è possibile riutilizzare quel componente nella schermata add-entity, nella schermata edit-entity e magari in una finestra di dialogo pop-up da qualche altra parte nell'applicazione, ad esempio. Ciascuno di questi casi d'uso richiede lo stesso modulo con la stessa validazione, ma è probabile che tu esegua azioni molto diverse su "invia".Il componente intelligente che ha invocato il componente stupido è probabilmente un diverso componente intelligente in ciascun caso. Aumentando l'evento e passando i valori al componente intelligente è possibile eseguire azioni molto diverse mentre si codifica la "vista" una sola volta.

Answer 4

In primo luogo, non sono un esperto in materia di esclusione di responsabilità.

• sento che i componenti intelligenti che controllano i componenti muto è in realtà quello che viene chiamato il modello mediatore. L'utilizzo di questo modello garantisce che un numero minore di componenti debba occuparsi dello store, migliorando così l'accoppiamento del louse.
• Facile manutenzione: Se devi rifattorizzare e rinominare azioni di massa è più facile farlo quando l'azione è presente in meno punti.
• Avere una postazione centrale che si occupa di actions consente una panoramica rapida dell'architettura. Anche lo scambio a caldo della logica di accesso store potrebbe essere più semplice.
• E come già menzionato: riutilizzo. È possibile condividere e riutilizzare componenti stupidi tra progetti che hanno o non hanno architettura ngrx.
• Anche riutilizzare nello stesso progetto semplicemente cablando diversi inputs e outputs. Es .: A dropdownComponent potrebbe avere molti casi che richiedono input e output diversi.