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
I would want to be keep the "functional core" part of the VM's responsibilities isolated.
Replying to
if we consider the VM to be made from a functional core and imperative shell, isn't it separate already? +
1