4 ms·
That's why UI architecture (at least on the web) has been moving toward an architecture where you have a single app state store and a unidirectional flow of app
by idibidiart 11y ago
That's why UI architecture (at least on the web) has been moving toward an architecture where you have a single app state store and a unidirectional flow of app state mutations (e.g. in Flux terms: from Action to Store and Store back to View but not the other way around) If you make the app state store immutable then you land in the sane model of having app state transitions (e.g. Redux) where you can have time travel thru app state, which is awesome and aids in debugging. The REST layer decouples server and client states, so we're just concerned with UI state here. Local state isn't avoidable I agree but should be reserved for things like animations that are outside the app state model (unless we're talking about interruptible, resumable, rewindable animations) ... Again, roughly speaking, but love to dig deeper.
- Aleman360 11y agoThat's generally what you try to do in MVVM apps too... you have some "service" that stores all the state. User input goes: View -> ViewModel -> Service and the data goes Service -> ViewModel -> View However, the same app state may be presented in different ways in different parts of the UI. Those different ways could each have their own ViewModel for transforming that state as needed for its presentation. Poorly architected MVVM apps have lots of inter-ViewModel dependencies... that's where you wind up with state spaghetti.