These are chat archives for jdubray/sam
Thanks for great discussion so far about SAM, I learned a lot from that. I have built a small Contact Manager using SAM pattern, I posted source code to github, here is the repo:
Would you please take a look and have comments on it?
I’m not good at talking about state, imitation, mutation… so I hope my code can explain my understanding about SAM.
anyone worked with incremental-dom?
@devinivy does it work the same way as snabbdom?
I like SAM because I can start working on anything I want
without thinking of Redux/React or Angular + the ecosystem around these framworks
I like that quote...
but It seems to me that you could factor your code like SAFE such that the CSP code does not show up in the
i will check this.
It looks to me that streams are part of the Cargo Cult of Reactive programming:
Pure functions without side effects
Immutable values, strict types
Functions operates on (immutable) streams of values
No mutable state (global or local)
SAM is "step-based" in other words you must perform the loop (A->M->S) as a unit of work (a step) before you can process another action
yup, i understand this.
streamthings, so i cannot clarify your points about streams
model - state - views - actions - model
Perhaps the model could be decoupled, i.e. the model is independent and not tied to anything else (namely, not tied to state to call state.render directly). I think this is what @imnutz did in his example with the use of js-csp. @jdubray I think you approve of this, yes?
So any wiring approach that is based on a one-way message paradigm will work (observers, pub/sub, csp,...)