These are chat archives for jdubray/sam

Jun 2016
Jean-Jacques Dubray
Jun 12 2016 09:08
Now imagine a world of Observables and/or Promises that listens to user/other events
And compare it to a SAM/PAL world where we systematically keep track of:
  • allowed actions (which event event/intent triggered the action)
  • steps (the order in which actions are triggered)
  • model mutations
Not sure which programming model you would find easier to reason about/use to write your code
Jun 12 2016 20:23
@jdubray "Now what I don't like is: Vuex stores are reactive" -- I believe you can take control and manual trigger the update.
Jean-Jacques Dubray
Jun 12 2016 22:25
I prefer a state function/learner which composes/updates the view based on the mode/application state.
Jean-Jacques Dubray
Jun 12 2016 22:30

Things like MobX or React are just too reactive
V = f(M) is really,
1/ figure out the current control state/status
2/ if changed compose a new view, if not update existing components which props have changed (no real need for a virtual-dom, IMHO)
3/ nap()

Not sure you can push 1/ and 3/ to components
Without the State function/Learner, the Model would have to conform exactly to the view component props, an unhealthy coupling IMHO.

Redux quickly introduced the concept of "containers" which are pretty much the state function
Did you take a look at Cerebral?
Jean-Jacques Dubray
Jun 12 2016 22:37
As I understand it, frameworks like MobX make it a bit harder to compute the control state because they don't have a single state tree. They assume the model can be fragmented along the lines of GUI components, not sure this is generally true.
Michel was the first one to admit that MobX is the tail of your application model, you can put whatever you want upfront (such as SAM, which would update the observables).
That's why it's important to define your programming model, whatever framework you choose.
The same thing would be true of a Store <=> Component reaction. The State function/Learner would have to populate that store, not the Reducer.
Jean-Jacques Dubray
Jun 12 2016 23:05

Dan explains redux

there are no setters.

instead there are statements like these:
{ type: 'SET_VISIBILITY_FILTER', filter: 'SHOW_ALL' }
and he continues:

To change something in the state, you need to dispatch an action. An action is a plain JavaScript object (notice how we don’t introduce any magic?) that describes what happened. "

Jean-Jacques Dubray
Jun 12 2016 23:16
No, "describing what happen" is not even close, you need to translate "what happened" into the proposed changes to the model, then mutation can start. It shouldn't be the role of the acceptor to derive the values that the model should mutate too.