These are chat archives for jdubray/sam

Feb 2016
Jean-Jacques Dubray
Feb 11 2016 00:14
I added some thoughts on SAM and Redux in the sam-architecture room.
The gist of it is that the Redux semantics are fundamentally broken and people should stop using it right now, it will lead to the same spaghetti code that Flux lead to, just a different flavor.
Danny Moerkerke
Feb 11 2016 08:46
gmariani did raise some valid concerns about event handlers that will be lost when a view is updated. How should we go about that in SAM?
Jean-Jacques Dubray
Feb 11 2016 09:37

Point taken, let me reply to this paragraph which I think you are referencing:

I was working a bit more on my application (skipping SAM structure until I understand it better) and had some AJAX functions on button interactions. I pondered on that for a bit, does that go in the Model after an action triggers it or in the action and only updates the model once the result is available? The latter I'm thinking? There seems to be a lot of non-important miscellaneous logic that doesn't fit neatly into the SAM model (alerts on form validation, ajax calls, etc.)

The whole goal of the pattern is to eliminate Ajax calls from the View, so that's bit unfair to say they don't fit in the pattern. That's by design In the "Change of Address" example in the paper I showed how APIs fit below the actions (for API which have no side effects) and the model (persistence APIs). So yes, it is the later: " in the action and only updates the model once the result is available"

for alerts, I'd say since you have to go through the reactive loop, that's probably the part that would look a bit heavy in SAM, but at the same time, you probably want the model to know the state (why the alert dialog popped up?).
@DannyMoerkerke did I miss something?
Danny Moerkerke
Feb 11 2016 19:22

@jdubray thank you but I was actually referencing this paragraph:

What happens when you just want to update a view with new data from the model? I don't want to destroy everything redraw it and re-add listeners every time. Also in your example you called the action function where the form submits. But if there are two buttons that doesn't work anymore.

Jean-Jacques Dubray
Feb 11 2016 20:03
So, just to be clear, you can trigger as many action as you want from a given view. What I mean by "the whole goal of the pattern is to eliminate AJAX calls" is an interactive / MVC approach where the view makes a call and waits for a response and does something with it.
Jean-Jacques Dubray
Feb 11 2016 20:09
SAM, as a pattern (not a Framework) is flexible enough to be support multiple topologies. As I pointed it out in the figure above (fig9) you can deploy two instances that work in concert to avoid having to re-add listeners.
If we take a simple example, say a login panel:
<input id="username" type="text" value="username">
<input id="password" type="password" value="password">
<button class="button" id="login">Login</button>
Your handler is going to look like that (assuming the function V = S(M) is computed on the client):
$('#login').click(function() {
        var view  = document.getElementById("view") ;
        var session = $.post( "", { username: $( "#username" ).val(), password:$( "#password" ).val() } ) ;
                .done(function( model ) {
                    view.innerHTML = state.render(model) ;})
                .fail( function(data) {
                    view.innerHTML = state.render({error: "server error"}) ; })
    }) ;
Jean-Jacques Dubray
Feb 11 2016 20:15
You could also have the function V = S(M) computed on the server, in which case the server would return HTML directly.
It is just a slightly different factoring of the code. I cannot emphasize enough the benefits of separating the "effects from the logic" as André Staltz explains it as a core design principle of Cycle.js.
Jean-Jacques Dubray
Feb 11 2016 20:25
You probably would consider this API call to be an AJAX call, but I would say it is not, at least not a traditional one, because it is not because it is not orchestrated by the view. The view does not do anything with the response, the response is the view.
Now, I don't dispute the benefits of frameworks like Cycle.js, which offers a very concise way to implement the plumbing behind this kind of code, but I just want to make sure people understand the principles behind this kind of code. There are a large class of applications that can be written without any kind of framework, things like JSX, GraphQL, directives, and what not. Most people can return to a very simple way to built beautiful web site/apps.
SAM also brings balance between web designer, front-end and back-end developers.
Jean-Jacques Dubray
Feb 11 2016 20:35
Today, Frameworks like React.js and Angular put all the pressure on the front-end developer to deliver the app, that this wrong, plain wrong. The front-end developer makes call on what parts of the design can make it to the app based on his/her ability to code them and it architects the back-end because he/she absolutely want to use a template:
angular templates
When you understand the value of shifting from a template to a function, there is no turning back.