These are chat archives for jdubray/sam

10th
Feb 2017
majo44
@majo44
Feb 10 2017 09:18
Hello, I'm totally new with SAM.
I'm trying to understand the pattern and did not found the answers for questions. Why actions do not have access to model ? In examples I see action have to know the model, because the data object is a contract between model and action. So if action is depend on model interface (present api) , why it can't directly access (even only read) to model. ? What is the purpose of such separation ?
Jean-Jacques Dubray
@jdubray
Feb 10 2017 10:35
@majo44 actions know the structure of the model since the proposal should be expressed as the property values we think the model should accept, but actions should not be able to query the current state of the model. They should translate an event into a proposal. They can enrich the event payload with some queries to another system.
Jean-Jacques Dubray
@jdubray
Feb 10 2017 10:41
SAM is a reactive pattern, the reactive loop is unidirectional, there is no "request/response" in SAM. Allowing any parts of the pattern to randomly query the current application state would create major concurrency headackes and make it difficult to deal with asynchronous actions, which are no problem for SAM.
majo44
@majo44
Feb 10 2017 10:50
Ok, I see and now I understand that by this you simple avoiding the race problem. Reale good point. But my concern with this is that in such case, like in example on the page. you are forced to split the logic of action between the action itself and model. I mentioned example validation of password, where action validate the password is not empty, but model validate it was used or not. Similar problem can occurs when we want to implement the transaction like flow, where we have sequence of few actions and fails of one of them should rollback effects of previous once, in such case model by self have to support such case, so have to have awareness about transaction.
Jean-Jacques Dubray
@jdubray
Feb 10 2017 11:19
That's actually a very good thing because that logic is very different in nature (compute the proposal vs mutate the application state). It allows a many-to-many relationship between the action and the acceptors (the units of work in the model that decides to accept/reject the proposal). The problem with traditional event handlers is that it's a one-to-one relationship. Action and model must be decoupled. That's one of the key value proposition of SAM.
When you take the example of the login, you would have an event payload with the username / password. The action will be responsible for "enriching" that event by authenticating the user and creating a proposal stating that the user is logged in or not.
Jean-Jacques Dubray
@jdubray
Feb 10 2017 11:28
The model keeps the transaction context, the roll-back happens with the next-action predicate. Here is an example of "reliable API call" managed by SAM (with retry): http://www.ebpml.org/blog15/2015/06/designing-a-reliable-api-call-component-with-sam/
Jean-Jacques Dubray
@jdubray
Feb 10 2017 11:35
Please note that actions are not composable, they are functionally composable (you can decompose a single action in multiple reusable functions) but an action must present a proposal to the model, which must complete the mutation before another can be processed.
majo44
@majo44
Feb 10 2017 12:08
Thanks @jdubray for really good explanation.
majo44
@majo44
Feb 10 2017 12:17
Small question. But is nothing wrong to provide the data from model to action as input params ? Eg. if I want to delete todo I will take item from view (which was taken from model) and have to provide it to action to know which todo have to be deleted. In same way I'm able to provide to the password change action, last password to made the validation it was used or not ? So by going to extreme we can always put the current whole model as a parameter to action :)
Rodrigo Carranza
@DrecDroid
Feb 10 2017 13:03
You have to pass the model to the view transforming It with the viewmodel function, the state function decides how to pass the transformed model to the view. The view is a function also, It could be stateful or stateless, is easier to use stateful views, you could mutate on any received data from the state function, if it is "stateless" the data could still be hold in the element attributes and extracted from them with the events.
Jean-Jacques Dubray
@jdubray
Feb 10 2017 19:37
yes exactly, the view will prepare the event payload which itself was generated from the last known model property values. The model may have advanced since then, you cannot be sure of the exact state of the model when the view sends an event. The idea is that the action should not access the current values of the model. I understand that sometimes this is not practical, there are cases where you just cannot send too many hidden properties in the view, just to get them back in the event payload. If you can avoid it, it's just not a good practice to query the model from the actions.