These are chat archives for jdubray/sam

Jul 2016
Mike Nichols
Jul 24 2016 06:43 UTC
@jdubray I have an interface that needs to be periodically (eg setInterval) refreshed with certain model 'status' values. This of course could be cancelled. It feels funny to setInterval inside the Model to keep itself synchronized with the service that provides certain status values. On the other hand, it feels funny to put it in State since now it is holding onto an interval that would be clearIntervaled , losing its 'pure function'. It is feasible to NAP the intervalId which is returned from a setInterval call inside the State NAP call but it feels odd to split interval tracking across SAM.
It smells like this is an outside concern to SAM and is just a service which periodically proposes (actions) the 'status' values to the model which may update itself and then continue the normal SAM loop into the learner/State for refreshing the viewModel.
Where does something like this polling-for-synchronization sit in your mind?
Jean-Jacques Dubray
Jul 24 2016 07:08 UTC

In general I would say this looks like an action, and that action would be triggered by nap(). It depends the kind of precision you need (you certainly can't get real time) but the way I would do it is to use setTimeout not setInterval.

refresh: (data: any, present?: (event: any) => void) => {
            present = present || _present ;
            data = data || {} ;
            data.refreshed = true ; // can trigger a new refresh cycle once this is presented
            var d = data ;
            var p = present ;

            setTimeout(function() {
                   // refresh
                    p(d) ;
            }, 1000) ;

The model would keep the application state whether you need refresh or not. A cancel would simply be achieved by presenting {refresh: false} to the model.

things could be a bit more complicated if you need to nap() other actions, so nap() would need to compose these actions:
an interval would be part of the application state, so the next best place would be to keep a reference to it in the model, if you feel you absolutely need to use a model.
Fred Daoud
Jul 24 2016 13:52 UTC
@jdubray I checked out your example, it looks pretty good. Nice use of mobx along with sam.
I was a little surprised though to see that RocketLauncherView is tied to State. Normally you (and I agree) keep views decoupled. So each view would be independent, and it is the State that would contain the logic of which view to use for the representation.
Jean-Jacques Dubray
Jul 24 2016 21:18 UTC
this is really a first pass. The difference with MobX is that the view is directly wired to the state representation. The decoupling comes from @computable and @observable which act somewhat as a v=f(m) mechanism.
@foxdonut I think, just like react you need to use container components to avoid mixing the where with how.
Fred Daoud
Jul 24 2016 23:10 UTC
@jdubray :thumbsup: