These are chat archives for jdubray/sam

Feb 2018
Scott Conklin
Feb 05 2018 15:00
@jdubray Thanks. these recommendations are great. I think I know what you mean now.
@jdubray can you explain what you meant by this regarding spinners?: ">>another way to do it is to start the spinner in the view component when you need it "
Jean-Jacques Dubray
Feb 05 2018 16:13
This is a React SAM sample (I stole the approach from Dan himself).
@srconklin you can do something like this with a simple DOM manipulation (again, found the trick in Dan's repo):
 var Spinner = ({action}) =>  (
            <div id="spinner-component">
                <button onClick={() => { 
                        action({spinner: "spinner"})
                        document.getElementById("spinner").className = "loader"
                  Start spinning! 
                <div id="spinner" className=""></div>
You can then always render the view without a spinner, it's turned off, as soon as you render (assuming of course that's the right thing to do). That avoids creating an ancillary state machine to keep track of it.
One of the reasons why you want to do it that way is because the DOM manipulation is trivial compared to doing a fulling rendering and mutate the model with something like model.spinner = true
Jean-Jacques Dubray
Feb 05 2018 16:18
It's breaking a bit the paradigm, but as long as it's limited like this, I think it's ok.
devin ivy
Feb 05 2018 16:19
would there be something like model.spinner? my guess is that it would be computed in state most of the time.
based upon the current page and whatever data missing from the model.
Jean-Jacques Dubray
Feb 05 2018 16:21
@devinivy This is just the simple case where you the async operation is either a query in the action, or a command in the model. Once it completes, the rendering is always without a spinner. That's why it's ok to start it from the view component. Again, not ideal from a logical perspective, but easy to reason about. I would argue easier than using an ancillary state machine based on model.spinner
I would actually recommend avoiding using ancillary state machines as much as you can, that's why I find the SAM pattern so helpful (due to it's temporal structure). You should keep FSM semantics for the application state, not ancillary operations, say like Redux which abuses them (you need to keep track of every request/response - really??)
Scott Conklin
Feb 05 2018 20:05
@jdubray is it not considered an ancillary state machine to have an errors object for when validation errors occur?
Jean-Jacques Dubray
Feb 05 2018 21:13
@srconklin I would not consider them as such because they are atomic, either you are in an invalid state or not
\\ in the state function, invalidState is derived
invalidState = a_function_of(props)

\\ ancillary state machine is drive by mutation
\\ step1 
model.loading = true
\\ then step 2 or step N
model.loading = false
It's better to remain functional (state function) as much as you can and only use mutations as little as possible.
The whole point of the SAM pattern is to avoid using Finite State Machines, even though it's compatible with them.