These are chat archives for jdubray/sam

6th
May 2016
devin ivy
@devinivy
May 06 2016 02:16
@jdubray is there an example of parent and child SAM components working together?
Jean-Jacques Dubray
@jdubray
May 06 2016 02:17
No, sorry, it is not that different, it is just that one action of the child view is wired to the parent.
The action can also be called by nap()
When the child runs in the browser, the difficulty is more in instantiating the child because you would have to load potentially all children's code such that it is available when the child view is instantiated by the parent.
Otherwise you'd have to do some form of hot loading
When the child runs on the server then it's no problem.
Parent/Child is a really about having two separate models. This is often what happens in the case of a Wizard (complex form). The user would go through some steps to gather information and then at the send, you'd submit the whole dataset to the parent model, via a parent action
devin ivy
@devinivy
May 06 2016 03:57
so in the case of parent/child, they would each have their own present(). how would an action target presentToParent() versus presentToChild()?
Jean-Jacques Dubray
@jdubray
May 06 2016 08:52
Yes, they would have their own model, which would implement a distinct present method. The parent would instantiate the container in which the child instance is rendered.
Assuming all the actions are wired to a single dispatch method you could implement the following strategy:
function dispatch(data) {
            // client side
            if (data.child !== undefined) { 
                   childModel.present(data) ; 
             } else {
                   // server side
                  $.post( "http://localhost:5425/app/v1/dispatch", data) 
                      .done(function( representation ) {
                               $( "#parent-representation" ).html( representation );
                       }        
                   );
            }
        }
The way this dispatch method would work is that in the case of the child pattern, the action is executed on the client (the reactive loop will continue and render the result), while in the case of the parent, the client-side code will marshall the action invocation which will call that dispatch method.
Jean-Jacques Dubray
@jdubray
May 06 2016 08:59
You could also make it more decoupled, but the problem is wiring the elements, it's a bit harder to do the wiring dynamically. I have not thought about it enough to answer your question.
If you use an "actions" singleton, I guess you could keep adding/removing individual actions to it, such that the view components could be designed generically:
onclick="JavaScript:return actions.' + intents['edit'] +  '...
Jean-Jacques Dubray
@jdubray
May 06 2016 09:05
What do you think?
devin ivy
@devinivy
May 06 2016 19:10
the only thing i'm confused about is how there's any sort of child/parent relationship there, aside from simply naming them as such. aren't the parent and the child symmetrical to each other the way you've described it?
i really want to have this parent/child conversation, because i think begins to address the architectural/codebase organization of a larger app that @HighOnDrive and I are asking about. i did also want to mention that this is an interesting solution: https://github.com/reactjs/redux/issues/1528#issuecomment-198352851 to dan abramov's question. i like that it doesn't rely on continuations.
Jean-Jacques Dubray
@jdubray
May 06 2016 19:44
There is an instantiation relationship, the parent "wires" the child. You may also have peer instances, but you need a 3rd party to wire them.
That being said, in relation to the comment you are pointing out, here are the two issues I see in the redux community:
  • Sagas are stateful, by design/definition
  • Reducers as just simple synchronous functions
People should stay away from Sagas, the single state tree(s) is(are) essential to Front-End Architectures (There is plural for independent trees Parent/Child, Peers)
The problem of making the Reducer synchronous is that it forces the "programming step" to look a certain way, IMHO, their notion of Step in artificially constrained. And for all intent and purposes they actually don't think in term of "Step"
Jean-Jacques Dubray
@jdubray
May 06 2016 19:49
So let's go back to the beginning, what is reactive programming?
Reactive programming is about explicit dependencies:
A = B + C
does not just mean compute A as the sum of B and C, it means, each time B and/or C changes then A always hold the value or the sum, at any point in time
There is a glitch in RP, a glitch (it is literally called a glitch), the glitch appears when you have something like this:
A = B + C ; D = B * C
Jean-Jacques Dubray
@jdubray
May 06 2016 19:55
A is computed before D, changes cannot propagate instantly to the entire application state / Model
Redux says no worries, we'll make the reducer synchronous, hence "glitch free"
devin ivy
@devinivy
May 06 2016 19:56
i see– there is a moment that A is up-to-date with B and C, but D is not.
that's okay as long as nothing happens during or between those calculations.
Jean-Jacques Dubray
@jdubray
May 06 2016 19:57
Yes, exactly
devin ivy
@devinivy
May 06 2016 19:57
(of A and D)
Jean-Jacques Dubray
@jdubray
May 06 2016 19:57
The idea behind TLA+, Paxos, and hence SAM is to say, it does not matter what you do as long as you "synchronize" the critical section
devin ivy
@devinivy
May 06 2016 19:58
what's the critical section?
Jean-Jacques Dubray
@jdubray
May 06 2016 19:58
You don't allow a new step to start until you completed whatever you call a step
the critical section is the mutation section (Accept)
In propose you are safe, you can launch as many proposers as you want
devin ivy
@devinivy
May 06 2016 19:58
gotchya! this is really good simple material.
Jean-Jacques Dubray
@jdubray
May 06 2016 19:59
They are using the theory of Reactive Programming to the nth degree
there is no need for that
I can call an API in the accept (critical) section, nothing wrong with it, as long as I decide it is legitimately part of it
The key is to have clarity, you know when you leave the accept phase, there is no need to make that phase synchronous
However, it must be "synchronized", otherwise you have "glitches"
That's why they are having all these debates around async vs sync, that is the wrong debate.
Jean-Jacques Dubray
@jdubray
May 06 2016 20:04
What's hilarious is that they are ready to introduce a Saga just to deal with that non existent problem. Crazy if you ask me. Sagas will destroy redux because you will start warping the async part of the reducer into a separate element.
The key is to define a step to be as narrow as you can but not narrower. That's the role of the proposers. That's why in particular they need to propose model values such that the model, is just concerned with executing the assignments and refreshing the dependencies to exit the critical section as quickly as another action would need to be trigger (which in a GUI is not that fast).
Jean-Jacques Dubray
@jdubray
May 06 2016 20:12
My talk on SAM at nodepdx has been accepted, that's what I will talk about.
devin ivy
@devinivy
May 06 2016 20:12
cool!
Brian Haak
@avesus
May 06 2016 20:33
You guys are awesome here. Love your boat ;-)
devin ivy
@devinivy
May 06 2016 20:35
@avesus i looked quickpaster and like how you pieced it together :)
Jean-Jacques Dubray
@jdubray
May 06 2016 20:42
sorry, I missed it, what does quickpaster do?

Here is what people think RFP is

The main idea of RFP is to build programs in a declarative only way, by defining what are the streams, how they are linked together and what happens if a new stream value arrives over time.
Programs such as this can be built with very little to no application state variables, which are in general a source of errors. To make it clearer: the application does have state, but that state is typically stored on certain streams or in the DOM, not on the application code itself.

Note the "can be built with very little to no application state variables"
So when you look at Cycle.js you get that: "state is typically stored on certain streams or in the DOM"
Redux is a bit cleaner, because of its store
brusand
@brusand
May 06 2016 21:46
@jdubray as you speak about praxis, i used an actor: akka and the agent model is closed to sam. You présent message to an actor and the actor is a kind of front office who dispatch message to workers who send back a response. Actor is sam model . only one entry to compute the message.
Akka use praxos for clustering
But it is in java world but the concepts are interisting
Stardrive ENGG
@HighOnDrive
May 06 2016 23:40
@devinivy I love how clearly you put it on the Redux issue with " It's those steps/proposals that are controlled, not the actions themselves." :+1:
Stardrive ENGG
@HighOnDrive
May 06 2016 23:46
@jdubray Right, CycleJS just advocates the one option, which is storing state in live streams or the DOM. IMO, this might work for simple UI's but when you have a feature rich app with many tools that may also have multiple sub-modes it all bogs down, if you follow the typical CycleJS pattern.
I'm all for utilizing live state in streams but the streams should be intelligently utilized not just spawned for every thing imaginable, simply because CycleJS offers no better idioms.