Marc (34) [Avatar] Offline
Good job. Thank you.
"State" is perhaps the most pernicious topic in software engineering.
On page 53 you explain how the ViewModel class should be stateless, while it should obtain its state from the Model.

What about the state of the UI? For example, visibility of widgets?
I understand it is the ViewModel's responsibility to change the state of a widget. True or False?
Where should that state be remembered? In the properties of the widgets themselves?

Thank you,
Jim Bennett (88) [Avatar] Offline
Depends on is it transient state or persisted state.

What I mean is - the view model should be able to be thrown away and recreated from the model layer at any time. It's unlikely that it ever would be, but if you code it this way then you ensure state is kept in the right place.

Sometimes there is state you want to show in the UI but don't want to persist - calculated values derived from model data, temporary user input that has failed validation. That can live in the view model - you wouldn't want to persist an incorrect phone number in your database for example. Think about a form on a web page - if you refresh it you lose the data you entered, but when you click save the data is saved. You could store the values for a form in the view model and only push them to the model after validation when the user clicks save.