That'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 t

That'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.