These are chat archives for jdubray/sam-examples

10th
Aug 2016
Felipe Matos
@imfelipe
Aug 10 2016 15:44
I'm having trouble understanding how to deal with events that (I think) don't change the model. Say I have a button "Create new user" that displays a dialog to input user data. This action ("display dialog") is somehow managed by the model? There are no data to be evaluated by the model, only fancy visuals, so would I need a flag on the model to identify this click event? Or this event would be outside the SAM cycle?
Jean-Jacques Dubray
@jdubray
Aug 10 2016 15:51
@f-matos yes, in general this will be mediated by an action-model-state loop. The action will translate the event/intent into a proposal to the model (displayDialog:true), which the model could accept or reject based on the application state. The state representation will render a dialog. In general you want 100% of the application state to be managed by the model.
Felipe Matos
@imfelipe
Aug 10 2016 17:19
Doesn't this create a lot of complexity to the model? The more actions you have, the more states you have to deal with and more bloated the model is.
If for every action all states are evaluated, it'll become troublesome to prevent side effects (as in, one action proposal affects an unintended state), unless you start naming your proposals "SpecificNameThatImSureIsUniqueFlag"
Why should the model care - or even know - about the view presenting a dialog? Unless the state "dialog open" intentionally changes how other elements behave, I don't understand why would it be beneficial to give this information to the model.
Felipe Matos
@imfelipe
Aug 10 2016 19:48
When I say "If for every action" I actually mean "If for every UI change".
Jean-Jacques Dubray
@jdubray
Aug 10 2016 23:15
Everything is tradeoff. Single State Tree approaches are becoming pretty standard these days. People have tried to decompose the application state in components and that's not pretty.
Please note that SAM supports parent/child instances so the effect that you are talking about is not given at all. These ancillary aspects of the application states should be implemented that way and the parent model should only be presented with key proposals such as a { newUser: {name, ...}}
@f-matos For small UX effects, such as a spinner, it's ok to manipulate the DOM onEvent as long as the resulting state does not need to know it happened (it will be automatically cleaned up on the next rendering of the State representation).
Jean-Jacques Dubray
@jdubray
Aug 10 2016 23:26
The key to understand the SAM pattern is that with SAM you are/need to be always in the position of associating a "unit of work" to an event. Component publish events, they have no idea what happens next. The unit of work is responsible for changing the application state. The problem is when you think you are better off working locally and ignoring global application state changes. There is a (rather big) mismatch between the view and these units of work, they can't be driven by the view. You need "adapters" that will translate these events into the call that will ultimately be responsible for updating the application state. Coupling events with application state mutation is, IMHO, the worst thing you can do.