Yes, for sure, but it fails to answer: how should we structure the stateful shell?
Conversation
What’s the specific question?
1
User presses the "sign up" button. Who controls the state machine related to the resulting effects?
1
Original view model yields the new view model, original VC notices that and pushes on the corresponding new VC.
1
I don't mean UI-wise; in response to "sign up," you make some network request; when you get an ACK, persist a value, etc.
1
The view model is responsible for coordinating that request-response chain. The details of it should live in the model.
1
What if the state machine related to that network request has a different lifespan than the UI related to it?
1
These questions are hard to discuss in the abstract. That Can Be Represented, but It Depends On What The Request Is.
2
Sure. Broadly, my concern is that the approach you suggest will lead to lots of stateful effects living in the view model.
1
Yes—in many ways, that’s the point.
3
Replying to
e.g. a presentation-oriented transformation of a model value to some view-appropriate value.
Replying to
Ours contain logic like that too. It’s unfortunate, but I rationalize it as:
1
Consumers of the view model (views, basically) should be agnostic as to whether a particular transformation is stateful.
2
Show replies