These are chat archives for jdubray/sam

11th
Feb 2017
Jean-Jacques Dubray
@jdubray
Feb 11 2017 00:33
Meet hyperapp https://github.com/hyperapp/hyperapp, not full SAM yet, but lots of potential
Marcus Feitoza
@mfeitoza
Feb 11 2017 02:13
Hi JJ, i'm busy in last month I'm move to new house and other question.
I started a more complex Mithril example, but is not finish.
Looking in HubSpot open source i found this:
https://github.com/HubSpot/general-store
So my point is to pick the general concepts and port to SAM.
I'll finish reading Specifying Systems and start think more about
Jean-Jacques Dubray
@jdubray
Feb 11 2017 04:15
I would be careful, the semantics of the general-store are a bit at odds with SAM principles. They align somewhat with the State Representation in case you have multiple subscribers (that may also poll it). The model is innaccessible, outside of SAM, only the state representation is.
Fred Daoud
@foxdonut
Feb 11 2017 18:56
@jdubray and friends I am working on a new version of Meiosis, based on (very simple) streams. Right now I am using flyd, but plan to make it compatible with mithril/stream as well. I wanted to share the concept with you. Here is the rocket-launcher example: http://codepen.io/foxdonut/pen/JEeqPY?editors=1010
Notice that model.present is implemented as "units of work" (similar to "acceptors" which I think was termed earlier on this channel.)
Also, there is no longer a need for constants, or checking proposal properties, or union-type etc. to determine the nature of the proposal. Instead you can use proper object properties.
Fred Daoud
@foxdonut
Feb 11 2017 19:02
Finally in a (soon to come) more complex example, I will demonstrate the clean transition from [ UI event ] -> [ intent ] -> [ action ] -> [ model change ], again without need for constants, thanks to stream.map. Please note that I am purposely using flyd (or soon compatible with mithril/stream) because they are very simple and effective and do not make your code complicated as when using RxJS.
As always, credit to @jdubray for always explaining the details of the SAM pattern. I particularly like how intents become actions, and then units of work (model changes/acceptors).
Jean-Jacques Dubray
@jdubray
Feb 11 2017 23:31

@foxdonut thanks! I am always a bit skeptical of handling the control for to a stream. In the latest example that I have written I have componentized the acceptors (I think it's a better name) but I still have to test if a given acceptor is activated.
In some ways you do that to because every stream is guarded by a condition:

if (state.counting(model)) {
        model.counter = counterValue;
      }

This example is very heavy on "state machine" semantics. I would be interesting to use a different example like ToDo list which is more data model centric. Ultimately real-world apps are somewhere in between.

I am also a bit concerned with the coupling model/state, ideally you don't want the model to know too much about the state function. The model may rely on some basic internal state machines to control the updates, but it is expected that the state function will represent a far richer/dense state machine. For me it is essential to keep that delineation very clear, it's very hard to reason about your system when they are coupled.
On another note, it looks like Cycle.js has converged with Redux and Elm and is now based on a single state tree: https://github.com/staltz/cycle-onionify
Can't wait to see cycle-sagas, I suggest calling that library "knot" :-D
Jean-Jacques Dubray
@jdubray
Feb 11 2017 23:38
@sladiri has publised a SAM implementation using function generators: https://github.com/sladiri/sam-simpler
there is the part of me that like the elegance of that implementation and then the other side that thinks about middlewares (say like SAFE) that you would want to deploy as needed. If we could do both, I think that would be a nice break-through.