These are chat archives for jdubray/sam

20th
Jan 2017
Jean-Jacques Dubray
@jdubray
Jan 20 2017 02:52
Another Cargo Cult is emerging before our eyes/fingers: mutation is better dealt with immutability
https://www.toptal.com/javascript/immutability-in-javascript-using-redux
How broken is React's programming model? https://twitter.com/AdamRackis/status/822162375101059072
devin ivy
@devinivy
Jan 20 2017 13:50

@jdubray i really think what we need is a common interface to mutations, continuing down the path of cerebral's state-tree. there's nothing inherently wrong with immutability, aside from its benefits being misunderstood and not applicable broadly. it's happening in polymer-land too!

see my comment here, https://www.youtube.com/watch?v=PahsgJn0sgU&lc=z12aet5rzpq5xb1yc04cgx2bpnmuhdbjwlo0k

rob dodson recognizes that immutability wont jive with polymer– i just wish he had mentioned that in the video.
i imagine our reducers looking more like (state, action) => mutation => nextState, where there's room for an adapter to decide how that mutation is applied to the current state. the adapter could perform mutations on plain objects, could perform immutable changes to plain js objects, could apply updates to immutablejs objects, could update observables, etc.
Jean-Jacques Dubray
@jdubray
Jan 20 2017 16:41
There is nothing inherently wrong other than:
a/ you don't need it, it's just pure overhead
b/ does not work in as-is concurrent environment
c/ if (re)enforces the wrong structure between action and model
This is pure Cargo Cult in the sense that as a community we refuse to look clearly as to what we are trying to accomplish
Jean-Jacques Dubray
@jdubray
Jan 20 2017 16:49
The underlying assumption between "immutability" is single state tree and React/Redux has never been able to achieve Single-State tree. Can you imagine writing React apps without a true single state tree? me neither.
At the end of the day, that's not my problem but we are losing a big opportunity to clean up the mess for no reason other than a few people make pretty diagrams and talk nicely.
Artyom Shalkhakov
@ashalkhakov
Jan 20 2017 17:00
Hello all! I've written this code: https://github.com/ashalkhakov/sam-tetris -- could you tell me if I understood SAM correctly?
You can play tetris here: https://ashalkhakov.github.io/sam-tetris/
Jean-Jacques Dubray
@jdubray
Jan 20 2017 17:04
its awful, I am going to play Tetris all day now! :-)
wow! this is very nice. I'll look at the code later this evening.
Jean-Jacques Dubray
@jdubray
Jan 20 2017 17:25
@ashalkhakov you are very close. The part of SAM you did not implement is the "next-action-predicate". It could be used to request a new animation frame rather than doing it that way (the request being an action):
function frame() {
        now = timestamp();
    // using requestAnimationFrame have to be able to handle large delta's caused when it 'hibernates' in a background or non-visible tab
    model.present({interval: Math.min(1, (now - last) / 1000.0)});
    var repr = state.representation(model);
        draw.draw(repr);
        last = now;
        requestAnimationFrame(frame, canvas);
    }
Other than from what I can tell it's SAM's
the next action predicate would include the setTimeout
function(callback, element) {
            window.setTimeout(callback, 1000 / 60);
        }
devin ivy
@devinivy
Jan 20 2017 18:37
@jdubray immutability absolutely makes sense for usage with react. do you want shouldComponentUpdate() to do more than pointer comparison?
vanilla react and immutability go hand in hand. the issue is that it has created a fascination with immutability beyond what is appropriate.
Jean-Jacques Dubray
@jdubray
Jan 20 2017 18:41
Yes I understand that, this because of the way the setState({}) method works. No question about it. What I question is the general idea that immutability is a good thing. We agree 100%
devin ivy
@devinivy
Jan 20 2017 18:43
:thumbsup: :beers:
fact: immutability is near-required for some view libraries (e.g. react) but does not work well with others (e.g. polymer). so if we truly want agnostic stores, we can't be locked into mutable or immutable structures.
so, we need a common api for mutation.
which is what i'm getting at with
(state, action) => mutation => nextState
Jean-Jacques Dubray
@jdubray
Jan 20 2017 18:47
IMHO this can be achieved with a change summary:
(action) => mutation => (state, changeSummary) => nextStateRepresentation
Immutability (kinds of) works because of vdom, you need a similar approach for application state, except that it's easy to assemble a change summary, unlike computing a diff.
devin ivy
@devinivy
Jan 20 2017 18:49
i agree at least that it is more SAMmy. will need to play with it more.
the issue there is that there isn't a general-purpose way to apply your mutation. how does that store work both for polymer and react?
Jean-Jacques Dubray
@jdubray
Jan 20 2017 18:51
sorry, need to head to a meeting. more later
devin ivy
@devinivy
Jan 20 2017 18:52
cool! thx for the chat. a short chat can make the work day go more quickly :P
Vincent Jo
@inrix-vincent-jo
Jan 20 2017 23:28
@jdubray hey JJ, I'm keep building this Alexa app.. right now the SAM architecture is there, but I want to allow only certain actions to be taken given a state. So the model would be responsible to check this is that correct? Or do I need a dispatcher layer to sit on top of model and state to 1) calculate the state of the machine 2) to see if that action or proposal is allowed. Thanks. Would love to get your opinion on this
Jean-Jacques Dubray
@jdubray
Jan 20 2017 23:29
The way I do that with SAFE is that the State function issues the list of authorized actions in the current state. A dispatcher would then check every new action request with that list.
@inrix-vincent-jo it's better to keep the model %100 decoupled from actions
Vincent Jo
@inrix-vincent-jo
Jan 20 2017 23:45
okay, I will give that implementation a shot thanks