These are chat archives for jdubray/sam

18th
Oct 2016
Jean-Jacques Dubray
@jdubray
Oct 18 2016 11:31
A big thank you to everyone for stimulating discussions and amazing contributions!
Kelyak
@kelyak
Oct 18 2016 11:35
Great article :D
Jean-Jacques Dubray
@jdubray
Oct 18 2016 11:58
@kelyak thank you.
Nivani
@Nivani
Oct 18 2016 12:30
Added to my learning backlog :)
devin ivy
@devinivy
Oct 18 2016 12:36

@jdubray

concurrency errors, including dropped events, data races, and starvation.

what is starvation?
devin ivy
@devinivy
Oct 18 2016 12:43
i also have a question about proposition versus the "least knowledge" principle. imagine a login screen appears as a modal over the page. when login succeeds, that modal should close. in by-the-book redux you would issue a LOGIN_SUCCESS action. one reducer might see that and update a portion of the model to isLoggedIn = true. another reducer might see that and update the model to isModalOpen = false. but in SAM is it wrong to say that the login action would have to propose { isModalOpen: false, isLoggedIn: true}, thereby requiring knowledge of both the application modal and authentication?
Edward Mulraney
@edmulraney
Oct 18 2016 13:20
wouldnt it just propose isLoggedIn = true
devin ivy
@devinivy
Oct 18 2016 13:42
who would deal with changing the modal's state? assuming the modal's state is not always derived from login.
Edward Mulraney
@edmulraney
Oct 18 2016 13:58
yeah good point - both places require knowledge of things they shouldnt necessarily have any knowledge of
Jean-Jacques Dubray
@jdubray
Oct 18 2016 19:31

@devinivy

In computer science, starvation is a problem encountered in concurrent computing where a process is perpetually denied necessary resources to process its work.

@devinivy that's a real good example since you need to invoke an API to authenticate the user, all that would happen in the action, and the proposal would be {isLoggedIn :true}
from what I have seen in Redux, they allow small DOM manipulation before entering the reducer. I have used the same technique in this sample
Jean-Jacques Dubray
@jdubray
Oct 18 2016 19:37
You just need to change the class of the modal (as I understand it):
<button onClick={() => { 
                        action({spinner: "spinner"})
                        document.getElementById("spinner").className = "loader"
                    }
                }>
In this sample I make a spinner appear.
devin ivy
@devinivy
Oct 18 2016 19:45
i see, hm! so you'd take the modal's open/closed state out of the model.
what about tracking in-flight requests application-wide? i have done this before to figure out whether to show an app-level loader (often a pulsing bar at the top of the page)
would each action make a proposal trackAsInFlight?
the way i handle this in redux-land is to split long-running actions into ATTEMPT, SUCCESS, FAIL actions. each attempt ups a counter, and each success/fail decrements a counter. but the actions do not care about whether they're being tracked. some app-level reducer just looks out for all attempts, successes, and failures.
Jean-Jacques Dubray
@jdubray
Oct 18 2016 19:55

so you'd take the modal's open/closed state out of the model.

that's border line, but mainly because HTML does not have a "state representation" for modals.

what about tracking in-flight requests application-wide?

It's better to use the standard model approach.

To go back to your question, there would never be a need to make this kind of proposal: { isModalOpen: false, isLoggedIn: true}

it is the state function which should translate isLoggedIn: true into isModalOpen: false, neither the action nor the model should focus on state representation!!!
devin ivy
@devinivy
Oct 18 2016 20:06
fair enough! all i mean to bring-up is that it's interesting when actions know about the model. i've brought it up before, and you've mentioned that reusable actions can be passed through adapters to make them application specific, which is a good point i have not tried yet.
the adapter basically turning a broad intent into an app-specific proposal.
Jean-Jacques Dubray
@jdubray
Oct 18 2016 20:09
there are two aspects:
  • event semantics do not express an intent (mouseDown vs Login), you don't want the model to know anything about events
  • intents vs units of work, intents are application specific while units of work to update the model, tend to be more general