Can I, Should I, How do I refactor per vuex - redux?

1

Abbiamo bisogno di ottenere molto più rigorosi sulla gestione dello stato nella nostra applicazione aziendale. Il cuore del nostro problema è un oggetto, chiamiamolo "TaxRefundApplication", che ha circa 20 proprietà, ma ci sono letteralmente centinaia di interazioni tra di loro. Le singole proprietà possono essere disabilitate o nascoste in base al valore di altre proprietà, possono avere valori predefiniti o valori forzati prelevati da altre posizioni, attivare il valore di altre proprietà ancora. Le proprietà numeriche possono avere limiti diversi a seconda delle combinazioni di altre proprietà. Le proprietà enumerate possono avere diversi insiemi di valori possibili ecc.

Esiste una struttura implicita in questa follia. Le 20 proprietà possono essere disposte come un grafico aciclico diretto (DAG), con proprietà come "TypeOfRefund" che influenzano dozzine di nodi downstream, ma almeno non c'è circolarità.

La mia migliore idea per il refactoring di tutto ciò era di rendere esplicito il DAG, per modellare una classe DAGNode, che avrebbe Rules [] e CandidateValues []. Qualsiasi nodo upstream potrebbe inserire una regola o CandidateValue in uno downstream. Qualsiasi modifica in questi 2 array richiederebbe al DAGNode di eseguire la sua regola di priorità e ricalcolare il suo valore. Un valore modificato potrebbe far passare nuove regole e valori candidati nei nodi downstream e richiedere loro di ricalcolare a turno. Questo ha molti vantaggi. Semplifica e rende esplicito. Ma rende anche le modifiche reversibili. Un nodo può avere solo un valore alla volta, ma se un valore forzato non è più forzato, il valore inserito dall'utente sarà ancora in CandidateValues [] e potrebbe essere ripristinato.

Poi mi sono imbattuto in Redux. Inevitabilmente, la gente molto più intelligente di me ha lottato con (quasi?) Lo stesso problema, e i motori di stato Redux / Elm / Vuex, con strumenti di debug, sono tutti pronti a partire. Ma non riesco proprio a vedere come il mio DAG può diventare un negozio Redux. Nel mio DAG, le regole di un nodo e i Candidate Valori sono pubblici. Non voglio scrivere un'azione specifica per modificare ciascun nodo diverso, voglio che siano tutti indirizzabili con questa stessa interfaccia limitata. Quindi, il mio problema si basa sul problema dello spazio di Redux, o dovrei perseverare da solo?

    
posta bbsimonbb 02.03.2017 - 18:22
fonte

1 risposta

1

In un modello redux, le tue azioni sarebbero cose come INSERT_RULE , INSERT_CANDIDATE_VALUE , DELETE_RULE e DELETE_CANDIDATE_VALUE , CHANGE_RULE , CHANGE_CANDIDATE_VALUE , con parametri per il nuovo valore e una sorta di indice . Il tuo riduttore prenderà quindi quell'azione e il precedente DAG e restituirà un nuovo DAG.

Dato che devi ancora scrivere il tuo riduttore, non sono sicuro di quanto questo ti aiuti effettivamente. È una sorta di ortogonale al tuo problema principale. Ma ottieni i benefici generali dell'immutabilità e delle transizioni di stato prevedibili, che non sono insignificanti.

    
risposta data 02.03.2017 - 23:32
fonte

Leggi altre domande sui tag