These are chat archives for jdubray/sam

12th
Feb 2017
Fred Daoud
@foxdonut
Feb 12 2017 01:40
@jdubray thank you for having a look at my example! Indeed the rocket-launcher is a bit particular example. But I followed your own implementation: https://bitbucket.org/snippets/jdubray/9dgKp/sam-sample#rocket.html-49
So I am not sure what you mean by the concern and coupling of model/state and it being "very hard to reason about this system" when it follows the same pattern as your own code.
Jean-Jacques Dubray
@jdubray
Feb 12 2017 01:41
Yes, I know, I am just saying that you have to balance state/data in your choices, because it's never that clear of a delineation.
Unfortunately, I was wrong in writing this code:
if (state.counting(model)) {
        if (model.counter === 0) {
            model.launched = data.launched || false ;
        } else {
            model.aborted = data.aborted || false ;
            if (data.counter !== undefined) { model.counter = data.counter ; }
        }
    } else {
        if (state.ready(model)) {
            model.started = data.started || false ;
        }
    }
    state.render(model) ;
Fred Daoud
@foxdonut
Feb 12 2017 01:42
But I agree that perhaps a somewhat more "typical" example like Todo would look different, and perhaps better.
Jean-Jacques Dubray
@jdubray
Feb 12 2017 01:43
I was just trying to reuse the functions (counting, ready...) but in doing so, I coupled state and model which is not desirable
Fred Daoud
@foxdonut
Feb 12 2017 01:43
Also, I agree with you that it would be nicer if the model was independent of the state function. Where would that check be instead, ideally? if (state.counting)
Jean-Jacques Dubray
@jdubray
Feb 12 2017 01:45
The problem here is that this sample is too state machine heavy, so you have to be careful making broad conclusions from it.
Fred Daoud
@foxdonut
Feb 12 2017 01:46
The problem with nap() using if (state.counting) is that it would be true, nap() would trigger decrement, but that results in the proposal "firing" 1 second later, and in the meantime, the user could press Abort.
So the counter would decrement one more time (incorrectly) after it was already aborted.
Jean-Jacques Dubray
@jdubray
Feb 12 2017 01:46
sure, I really didn't mean to use that code to launch a real rocket :-)
I just wanted to illustrate how the pattern worked in somthing that was more stateful because a lot of the samples at the time where very simple (react, ...).
Fred Daoud
@foxdonut
Feb 12 2017 01:47
Yes yes sorry if I sound like I am criticizing, I am not -- it's still a good example to discuss these issues.
Jean-Jacques Dubray
@jdubray
Feb 12 2017 01:48
I accept the criticism, but it's really illustrative, and I can even criticize my own code 12 months later. We all learn over time.
Fred Daoud
@foxdonut
Feb 12 2017 01:48
But otherwise I am liking this stream-oriented approach, I think it would work well in a typical data application.
Jean-Jacques Dubray
@jdubray
Feb 12 2017 01:49
It would be great to find a way to improve the way acceptors are wired in and enacted.
I understand the limitations of the conditions that I suggested using
Personally I like a lot the action/model delineation and maybe I am asking too much for the action and the model to be decoupled as much as possible. If the action knew which acceptor(s) to trigger, where would not be any need to guard the acceptors.
Fred Daoud
@foxdonut
Feb 12 2017 01:53
What I like about it is the streams are just a nice way of wiring things together, but you still maintain the single model principle; the model is still a regular JS object; you still have a clear "step"; you still have views as functions of the model; and you still have clearly defined model-mutation functions. Your model is not lost in a web of RxJS operators.
Indeed the mapping of actions to acceptors is more direct, which is why you no longer need to check for types or special properties on the proposal. The guard is just for this example because of the particular problem of async decrement vs abort.
Jean-Jacques Dubray
@jdubray
Feb 12 2017 01:57
As you know I am agnostic to wiring, I understand there are a variety of requirements and solutions, so I don't want to promote one over the other. That being said, one key advantage of the SAM pattern is the many-to-many relationships between actions and acceptors and that should remain. One action could potentially enact multiple acceptors or many actions could enact the same acceptor (with their own way of preparing the proposal).
This is what you don't get with traditional event/event handler approaches, including redux/elm. They have no way to achieve that at the programming model level, of course you are free to factor the reducer along these lines, but that's not what people generally do. The reducer is just a collection of event handlers.
(as I understand it)
Fred Daoud
@foxdonut
Feb 12 2017 02:01
Yes and those many-to-many relationships definitely hold in my wiring strategy. You wire an action to an acceptor, and you can definitely wire the same action to another acceptor, as well as wire the same acceptor to another action.
Would actions using state to determine whether it should fire a decrement proposal be better?
Fred Daoud
@foxdonut
Feb 12 2017 02:07
I have to say I am not sure I understand the problem with the model using state to determine whether it should accept the proposal. The model is ultimately the guardian, I would think it should indeed decide whether to accept the proposal -- based on state -- instead of trusting external code.
Maybe it's just a matter of -- semantics. In SAM, "state" is the function that produces a representation of the model, and calls nap() ... one could argue that "state" as it is being used in the model is not quite the same "state". It is just the utility functions using only model properties to determine a condition.
Is that what you meant?
Jean-Jacques Dubray
@jdubray
Feb 12 2017 02:27
It's really about being able to reuse the model with different state functions. With that in mind the common code should be tied to the model rather than the state function.
Rodrigo Carranza
@DrecDroid
Feb 12 2017 04:46
samsystem.png
Hi, this Is a diagram that shows how I'm implementing SAM at my project.
Any comments are appreciated :)
Rodrigo Carranza
@DrecDroid
Feb 12 2017 04:55
Jean-Jacques Dubray
@jdubray
Feb 12 2017 05:13
Thank you for sharing @DrecDroid - I'll be taking a look today.
Jean-Jacques Dubray
@jdubray
Feb 12 2017 07:35
@DrecDroid I looked at your diagram and it's perfectly aligned with the way I would think of SAM.
The component model sounds promising
Fred Daoud
@foxdonut
Feb 12 2017 12:49
Thank you for the review and discussion @jdubray -- always appreciated.
Rodrigo Carranza
@DrecDroid
Feb 12 2017 19:25
@jdubray I'll try to upload some examples soon, a simple todo maybe.
Jean-Jacques Dubray
@jdubray
Feb 12 2017 20:56
:thumbsup: