These are chat archives for jdubray/sam-examples

14th
Feb 2016
bjordan2010
@bjordan2010
Feb 14 2016 03:50

OK, I get what you are saying and it makes sense for creating components for reuse. MVC is hard to get away from once you use it like a hammer and everything is a nail. I am conditioned to the controller asking the model for it's correct "state" which I was trying to force into the state machine. The controller makes the request based on an action by the user or an "initial" view, and once is has responded then the controller passes the model's response to the correct view. But your use of state machine is for automatic actions.

So in my and gunar's Todo examples there are no real states because we don't have automatic actions. We only have the "View Inbox" and the "View archive" user actions. Data would indicate which action the user has requested. So I think you are suggesting that in model.present I only need to check data.inbox and data.archive to get the user's view choice, not state.inbox(model) and state.ready(model). Then I can filter the model based on the view choice and it would not be coupled with state. Likewise the view would be selected based on the user action that was stored in the model.

If the application ever needed to do something automatically then the state machine or if-then-else can be used to determine that the right state is reached before the view is displayed.

I made the changes in the take2 branch.

Jean-Jacques Dubray
@jdubray
Feb 14 2016 18:14
Yes, absolutely, in MVC the controller code would look like this big ball of mud:
outputs = A(inputs)
model = model.update(outputs)
nextView = S(model)
action = nap(model)
action(model)

If the application ever needed to do something automatically then the state machine or if-then-else can be used to determine that the right state is reached before the view is displayed.

be careful, because the next action is executed once the state is rendered, otherwise in the rocket example you would not see the countdown. After start you would see "launched". You first need to render the state and then start a new loop with the automatic action.

The challenge is of course to refresh the view after the automatic action has been executed, but that's not new, that's standard HTTP stuff. You could use WebSocket for instance.
I created another sample, the Item List is used by Redux and ngrx/core
Here it is:
Jean-Jacques Dubray
@jdubray
Feb 14 2016 18:20
sam-list: a list management example using the SAM pattern: https://bitbucket.org/snippets/jdubray/zr9r6
Jean-Jacques Dubray
@jdubray
Feb 14 2016 18:38
In your sample, I would try to filter the items from model as you render the view. I am not quite sure I understand the rationale for updating the model beyond the filter flag (inbox, archived).
That forces you to pass part of model as "data" from the action. In general, yes, you would want to have properties of the model passed down to the action and back to the model, but in general, they would come from the view (and potentially be edited by the user)
If you look at my last example (sam-list) it shows how the view embeds elements of the model that will be passed to the action.
It's preferable to not use data.xxx = model.yyy in the action
The action should be simply transforming the data passed from the view (changing units,...) and user input validation (but not integrity validation, that will be done in the model)