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
Ah, I didn't understand that you intended the view model to be imperative shell. My view models often contain many core bits.
Replying to
if you, say, use OS X bindings to connect the VM, it needs to have an imperative shell anyway, doesn't it? +