These are chat archives for jdubray/sam

30th
Dec 2016
Jean-Jacques Dubray
@jdubray
Dec 30 2016 01:43
I updated the Solstice Clock spec and created an API that provides the real-time angular position of the earth (the timestamp is in julian) unit)
https://www.linkedin.com/pulse/solstice-clock-jean-jacques-dubray
http://107.170.242.211:3000/api/v1/earth/orbital/position
Jean-Jacques Dubray
@jdubray
Dec 30 2016 01:53
There is not a more flawed assumption that the nodes of a distributed system are best represented by a pure function
http://www.thedotpost.com/2016/12/thomas-belin-user-interfaces-as-pure-functions-of-time
Every node is stateful and the inter-action protocol is independent of the node stateful coordination mechanisms
Jean-Jacques Dubray
@jdubray
Dec 30 2016 15:20
Fascinating discussion on Redux Action Creator vs Thunks vs Sagas (looks like now Dan prefers Sagas)
http://stackoverflow.com/questions/34570758/why-do-we-need-middleware-for-async-flow-in-redux/34623840
This discussion shows that the mix up of action/event semantics in the original Redux design creates a terrible coupling between components and actions. The view components should only publish event, by no means they should invoke actions of any kind unless they are wired dynamically (e.g. SAM's intents)
devin ivy
@devinivy
Dec 30 2016 15:25
typically in redux you'll use react-redux's connect() to link action-creators and the components however you see fit. many folks do just pass actions right on through.
Jean-Jacques Dubray
@jdubray
Dec 30 2016 15:26
Not sure how people can deal with that kind of programming model, 15 options to achieve the same result.
devin ivy
@devinivy
Dec 30 2016 15:29
my gripe with sagas is that they rely on language features that aren't used widely in any other context for the vast majority of developers.
ultimately they do essentially what you want– they add middleware that's decent at pushing long-running actions around.
Jean-Jacques Dubray
@jdubray
Dec 30 2016 15:30
IMHO, that's why they like to use them, it's so cool to use function generators... For me, semantically it's a terrible choice since it brakes the programming model, you can never claim to have a single state tree architecture
devin ivy
@devinivy
Dec 30 2016 15:30
well, that state is going to live somewhere, right? even in SAFE.
in SAFE does it live in the state tree?
Jean-Jacques Dubray
@jdubray
Dec 30 2016 15:31
yes, absolutely!
devin ivy
@devinivy
Dec 30 2016 15:32
that is nice. but hard to manage. i mean, with thunks you can always use getState() to check what actions are in-flight.
Jean-Jacques Dubray
@jdubray
Dec 30 2016 15:32
In SAFE, the only part that leaves outside the single state tree is the "allowed actions" and current step, they are immaterial to the model
devin ivy
@devinivy
Dec 30 2016 15:32
but it's difficult to manage.
Jean-Jacques Dubray
@jdubray
Dec 30 2016 15:32
spaghetti.js?
devin ivy
@devinivy
Dec 30 2016 15:33
lol :P
Jean-Jacques Dubray
@jdubray
Dec 30 2016 15:33
Actions should never have to call getState, that's a lot more important any kind of purity
You break everything by allowing "getState", only the model can tell you when the step is complete and it is "safe" to getState()
devin ivy
@devinivy
Dec 30 2016 15:34
true. in redux, moderation of actions should live in middleware.
but those middlewares will need to check the model. to tell what actions are in-flight, right?
Jean-Jacques Dubray
@jdubray
Dec 30 2016 15:36
Not in SAM, the only thing that SAFE does is check if an action is allowed in a given step. Without the notion of Step and clear boundary for what an action is/can do, I am not sure how you can write code, you indeed relying on the spaghetti.js lib (which comes by default with the langage).
devin ivy
@devinivy
Dec 30 2016 15:49
i think there are some stepping stones in between thunks calling setState() and SAFE. for example, using the idea of a step for only some actions and not for others.
Jean-Jacques Dubray
@jdubray
Dec 30 2016 16:02
Sure, there are a number of variations and optimizations you can implement, but the key is to have a clear enough programming model such that you never lose track of what you are doing. Redux originally had a clear "step" semantic but only in the synchronous case, then everything went south when they starting to add async behavior.