These are chat archives for jdubray/sam

16th
Feb 2016
Michael Solovyov
@msolovyov
Feb 16 2016 20:56
How can sam be factored out into components in different files? For example in the pure js rocket app, one person works on the displaying the counter, while another works on the button display, while another handles the mode/actions? So the button and the counter display need to both share the same data in model/actions.
Jean-Jacques Dubray
@jdubray
Feb 16 2016 21:06
It's just a question of "wiring" then. SAM would naturally help break the code into:
a) individual actions
b) model (which itself would probably be decomposed into different data triggers (if you choose a dataset approach, which is not necessarily always the best approach, I just happen to like it because it provides a good decoupling between the actions and the model)
c) the state
Each part can be unit tested 100% independently of the others
From a model's perspective, SAM is aligned with "event sourcing", so it's very robust in terms of its ability to "replay" a particular set of actions.
Michael Solovyov
@msolovyov
Feb 16 2016 21:44
what if you have state and actions in one file, and state and actions in another file needing to share a model? My js knowledge might be the thing limiting me
Michael Solovyov
@msolovyov
Feb 16 2016 22:19
For example, in the Flux frameworks there's a state+actions store in one file, then the view components in other files. That store gets registered with each view component resulting in both view components having the same synced data
Jean-Jacques Dubray
@jdubray
Feb 16 2016 22:21
I can't say that I have looked at all the wiring options and corresponding code structure
but there are a few design consideration that you want to be careful about
a) validate that an action can be invoked based on the current state
b) how the action gets its dataset, ideally you would want the dataset come from the view, rather than the action requesting model fragments directly from the model
This is not always possible, for privacy reason (you don't want all data to flow through the view)
c) the nap() needs to know about some actions, since nap is in the reactive path, it gets passed the model, so there is no issue here accessing the model properties to feed the action dataset
Jean-Jacques Dubray
@jdubray
Feb 16 2016 22:28
IMHO, the pattern decomposes as V, A+S, M. The view is a one or more functions, A and S need to often know about each other, M should be fairly independent, since that's the goal, I would avoid at all cost getters on the model and rely on the reactive loop to handle the data flow.
With respect to flux, the way the view is rendered in SAM is via a single function, which decomposes in many.
There are many ways to "wire" the pattern, including over HTTP. I would really recommend to rely on the reactive loop as much as possible and avoid transversal dependencies, with the understanding that A+S could/would have interdependencies.
Michael Solovyov
@msolovyov
Feb 16 2016 22:58
In your rocket example, how would you decouple the button code from the counter display code?
Jean-Jacques Dubray
@jdubray
Feb 16 2016 23:59
Yes, this is a great question, here we are wiring the view's event to the action. Personally, I would use a couple of strategies:
a) generate that code in the view (V = f(M)), but as it was mentioned, from a performance perspective, it might be prohibitive to bring a lot of event handers in the view (really depends on the volume)
b) if a) is not possible, I would use a "dynamic" wiring, group all the event handlers in a file (again for a really big app, you could break up this file into smaller groups of event handlers), the in the generated view, I would use the corresponding action name that binds to the handler.:
$('#action_name').click(function() { ...