La funzione annulla e ripristina possibile / fattibile con l'associazione dati bidirezionale (vs flusso dati unidirezionale)?

2

Sto sviluppando un'applicazione sperimentale per il lavoro che richiede annullamenti e ripristini completamente persistenti. Ho deciso di utilizzare lo stack tecnologico JS reattivo / riduttivo / immutabile per risolvere questo problema perché ho visto che funzionava bene .

In realtà sono davvero felice della semplicità della soluzione, ma il mio problema con questa decisione è che questa architettura e questo stack tecnologico si discostano da ciò che il team attualmente utilizza, che è un dati angolare / polimerico / di stile a due vie - architettura vincolante.

Quindi, nel tentativo di rimanere di mentalità aperta:

È possibile annullare e ripristinare possibili / fattibili con l'associazione bidirezionale dei dati quando si confrontano il flusso di dati unidirezionale e le strutture di dati completamente persistenti?

Perché o perché no? Come si ottiene un annullamento / ripristino completamente persistente con associazione dati bidirezionale?

Modifica

Dal mio commento qui sotto:

I am concerned with recording any change to the data model so the user can undo those. I have personally found success in doing so using immutable persistent data structures with 'uni-directional data flow' because I know where changes come in and where to save previous models. I can then emit a previous model and have react re-render when an undo action occurs. Now what I want to know is how to implement undos and redos that can track any change and undo it using two-way data binding architecture instead. I'm open to any solution that solves this problem using two-way data binding

    
posta Rico Kahler 25.04.2017 - 17:04
fonte

1 risposta

3

In genere implementa una funzione di annullamento / ripetizione utilizzando una cronologia dei comandi . L'interfaccia utente genera comandi con azioni eseguite e non eseguite e il modello sottostante viene modificato eseguendo l'azione di esecuzione del comando su di esso. Quindi la navigazione nella cronologia di annullamento / ripetizione sta eseguendo solo azioni eseguibili o non eseguite sul comando "corrente" e aggiornando il puntatore della cronologia al comando appropriato. Ciò significa che non si memorizzano i modelli completi per le voci precedenti, solo il comando che li ha prodotti dallo stato precedente.

In un legame dati unidirezionale il modo appropriato per implementare è fare in modo che l'UI generi direttamente i comandi e poi li esegua sul livello del modello sottostante. In un collegamento dati bidirezionale può essere un po 'più complicato, ma è comunque possibile generare la cronologia dei comandi dagli eventi sul livello del modello e quindi eseguire un po' di contabilità in questi gestori di eventi per impedire che vengano attivati quando si sta navigando nel comando cronologia e (dis) esecuzione dei comandi per aggiornare il modello.

In ogni caso, ciò che devi fare non è archiviare i modelli precedenti nella loro interezza. Hai solo bisogno del delta tra stati, e questo è rappresentato al meglio dal comando che ha generato la modifica.

    
risposta data 02.05.2017 - 09:29
fonte

Leggi altre domande sui tag