3 ms·
UI apps have all sorts of unavoidable copied state. For example, your data base might have separate fields for first name and last name, but your UI might conca
by Aleman360 11y ago
UI apps have all sorts of unavoidable copied state. For example, your data base might have separate fields for first name and last name, but your UI might concatenate these strings into a single one. Whether that's stored in a ViewModel or DOM is not a practical difference.
There's nothing about MVVM that says you have to copy Model state in your ViewModel either.
- idibidiart 11y agoThat'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.