These are chat archives for jdubray/sam

20th
Jul 2017
Slađan Ristić
@sladiri
Jul 20 2017 11:51
@jdubray You wrote that compound states are allowed but should be avoided. I have the feeling that only very simple models can get by without compound states. Does this mean, that I should split up the model instead?
For example if in state "logged-in", there could be different sub-states.
export function computeControlState(blog) {
  const states = []; // Allow compound states.

  if (!blog.posts || blog.posts.length === 0) {
    states.push(["empty", ["login", "postSystem", "cancel"]]);
  } else if (blog.userName) {
    states.push([
      "loggedIn",
      ["logout", "postSystem", "post", "deletePost", "cancel"],
    ]);
    // Could contain "sub-state", for example depending on number of user's posts.
  } else {
    states.push(["loggedOut", ["login", "postSystem", "cancel"]]);
  }

  return states;
}
Jean-Jacques Dubray
@jdubray
Jul 20 2017 13:37
Slađan Ristić
@sladiri
Jul 20 2017 15:46

new article on SAM with @sladiri @mfeitoza https://dzone.com/articles/the-three-approximations-you-should-never-use-when

Nice :)

Jean-Jacques Dubray
@jdubray
Jul 20 2017 18:47
@sladiri I really want to emphasize that SAM is not meant to be a "state machine" in disguise. It has just enough of the state machine semantics to guide your code to do the right thing, but thinking that your code should always be factored exactly as a classical state machine, is IMHO an anti-pattern in SAM. At least that was not my original intent. When you need it, it's there and you can make some important states explicit or detect unwanted states, but it's a mistake to think a large project could be implemented that way.
Slađan Ristić
@sladiri
Jul 20 2017 22:06
Thank you for the explanation. :)
Slađan Ristić
@sladiri
Jul 20 2017 23:23
I misunderstood you in that you always had to define separate states, ie. a state-machine.