Il concetto Flux / Redux sullo stato dell'applicazione pone dei limiti alle dimensioni dell'applicazione?

Question

Il concetto Flux / Redux sullo stato dell'applicazione pone dei limiti alle dimensioni dell'applicazione?

Naviga le tue risposte

#1 da (1 voti)

0

In Redux (implementazione React Flux) guida link si dice che

In Redux, all the application state is stored as a single object

Le mie domande sono:

Quanto seriamente dovremmo prendere questo principio? Per esempio. la mia applicazione può avere più entità come Persona, Fattura + InvoiceLine, Articolo, ecc. - Entità full set per l'applicazione ERP tradizionale. Ogni entità è gestita da un modulo separato all'interno dell'applicazione SPA. Abbiamo davvero bisogno di memorizzare ogni entità attiva (ogni fattura in fase di modifica) in un singolo Redux centrale e accedere alle sue proprietà all'interno di InvoiceComponent, ArticleComponen come this.props .... oggetti? O forse è meglio caricare quelle entità in oggetti this.state (usando Redux store come archivio temporaneo in cui gli oggetti si trovano nel tempo tra il recupero da backend fino ai componenti) e usa l'archivio centrale per i parametri di configurazione dell'applicazione (es. Registra i dati dell'utente , preferenze, ecc.)?
Se dovessimo inserire quasi tutto in Redux Store, come questo influenzi i possibili limiti dell'applicazione e le possibili prestazioni dell'applicazione. Qual è la differenza tra il negozio di Redux e la classe di Dio?

Forse SPA non è appropriato per il frontend delle applicazioni di tipo ERP la cui caratteristica è l'enorme schema di entità correlate?

architecture reactjs redux single-page-apps flux

posta TomR 05.06.2018 - 22:32

fonte

1 risposta

Leggi altre domande sui tag architecture reactjs redux single-page-apps flux

RenderAction è compatibile con l'architettura MVC? Test TDD lato client?

score 1 · Answer 1

Redux non promuove nulla di diverso dal minimo richiesto per il funzionamento della tua applicazione.

È uno strumento (principalmente) per passare i dati condivisi in un modo facile e semplice.
Dovresti pensare a come vuoi usare Redux nella tua applicazione. Scopri quali dati devono essere condivisi. Con un ERP sto indovinando molto, ma non necessariamente tutto.

Sebbene Redux promuova un'unica fonte di verità è possibile avere più negozi che è possibile combinare se necessario. Dipende interamente da come progetta la tua soluzione.

Nulla ti impedisce di avere una tonnellata di dati come stato locale o anche come oggetti di scena locali nei tuoi componenti e quindi di passare solo i dati che altri componenti necessiteranno nell'archivio di Redux.

In breve: non mettere tutto nel negozio Redux. Solo quali componenti multipli (cioè 2 o più) avranno bisogno.
Se questo risulta essere quasi tutto, allora è quello che è. Il modulo react-redux ti aiuterà a controllare esattamente cosa otterranno i tuoi componenti dallo store.

Considera anche i dati che esporti dal back-end.
Hai davvero bisogno di tutto dall'entità Person di essere nel frontend? Chiediti quelle cose e vedi cosa puoi minimizzare. Si vede spesso che quantità eccessive di dati sono esposte quando non è necessario.

Per quanto riguarda la scalabilità; javascript in generale è molto scalabile e se minimizzato e ottimizzato correttamente. Redux non è diverso e viene utilizzato in SPA molto grandi.

La domanda è stata riportata anche nel 2016 sul github di Redux con il problema # 1303 Redux Performance with Large Store e frequenti aggiornamenti che in sostanza ti chiedono di considerare moduli aggiuntivi come redux-ignore e redux-batched-subscribe .