These are chat archives for jdubray/sam

31st
Oct 2017
Jean-Jacques Dubray
@jdubray
Oct 31 2017 04:29

@zevenbergm I don't have time to look in detail at the question, but you can look at the strategy used to implement this code sample (canvas) where the state representation is expressed as a command/function to be applied to the canvas.

var stateRepresentation = {
                    rect: draw(model.rect.startX, model.rect.startY, model.rect.w, model.rect.h,model.color),
                    fishes: model.selectedFishes
                }

I am not sure this is applicable, it would depend on the API that is available to you.

The function is then called as the view renders:
net(net, fishes) {
         // draw the net
        net.rect(this.ctx,this.canvas) ;
        if (fishes>0) {
                var _fishes = (fishes>1)? ' fishes!' : ' fish' ;
                net.caught.innerHTML = " you caught "+fishes+_fishes ;
            } else {
                net.caught.innerHTML = "" ;
        }
    },
Paolo Furini
@pfurini
Oct 31 2017 08:39

@pfurini Thanks! Do you have any suggestions for a modern text editor?

As @jdubray said, I haven't so much time to look at it, but I can guide you in the right direction.. you have to find something like https://github.com/facebook/draft-js

Holger Winkelmann
@hwinkel
Oct 31 2017 08:39
@jdubray I'm followed now the talks and slides. One question comes to my mind about wiring of SAM based apps. As you are saying SAM is agnostic to wiring what would be your suggestion or sample for a SAM based app backend? Even you say the code is isomorphic how you communicate between Server and Client. i.e. based on the Modelchanges or based on the Statechange after the model change has happend on the server. Or are your samples always pure Client based?
Jean-Jacques Dubray
@jdubray
Oct 31 2017 09:16
@hwinkel no all samples are client based. The code would only be isomorphic if you use something like node.js.
The SAM-SAFE example shows the isomorphism:
  • client-only
  • client-server via a dispatcher on the client ( you can also keep the actions on the client and dispatch the model + state, or any combination: Actions on the server and model + state on the client, and so on)
  • you could also do the whole rendering on the server though I don't have a sample for that, I prefer running the view on the client at a minimum
Jean-Jacques Dubray
@jdubray
Oct 31 2017 09:21
The way I would structure the code is via a "reactive loop": (event) ==> action->model->state ==> (view)
Holger Winkelmann
@hwinkel
Oct 31 2017 09:22
@jdubray the reason for mentioning "isomorphic" was only the get a Client/Server Wiring exaample and a idea where the wiring should go, rather the really reuse the code self on the server. Currently we have Elixir based servers, so no reuse anyway.
Jean-Jacques Dubray
@jdubray
Oct 31 2017 09:23
In that case you can chose what runs on the browser: nothing, some, all (from event to view)
Then there is the question of how to "weave" API calls in the SAM programming model
Queries are generally invoked from Actions (Much much preferred). That's equivalent to Redux Thunks
Create/Update/Delete API calls can be either called from Actions or from the Model. I prefer calling them in the model because I feel they are synchronous to model mutation, and in general users expect they will get a transactional response to their request
Holger Winkelmann
@hwinkel
Oct 31 2017 09:27
Yes question would be how to build a wired API between client and Server. This API must somhow modeled after the requirements of the Commnication between the actions and the Sate Change "Call Back" I assume.
Jean-Jacques Dubray
@jdubray
Oct 31 2017 09:27
Alternatively, you could also trigger a "next-action" in NAP to call these APIs.
I tried to use NAP in one project for every API calls (queries and commands) and I was not happy with the result. That's how Elm and Redux generally do it, I find that approach to be suboptimal, and leads to maintaining lots of ancillary state machines
The beauty of SAM is that you can have an action that calls an API and then present the result to the model
function querySmthAction(intent) {
     http.get(query(intent))
        .then( result => model.present(result))
}
Holger Winkelmann
@hwinkel
Oct 31 2017 09:28
Therefore API a Server Exposes on the Wire would look very different as Classic CRUD REST or plain GraphQL as there would be a need to support the View State?
Jean-Jacques Dubray
@jdubray
Oct 31 2017 09:29
absolutely, totally orthogonal to SAM
I have to go into a meeting for the next few hours, I can continue the discussion after
Holger Winkelmann
@hwinkel
Oct 31 2017 09:31
OK, fine
Fred Daoud
@foxdonut
Oct 31 2017 12:24

@jdubray even nicer:

function querySmthAction(intent) {
    http.get(query(intent))
        .then(model.present)
}

:)

Holger Winkelmann
@hwinkel
Oct 31 2017 12:33
I must admit I'm not a coder, just try to understand / create a sustainable architecture pattern which we follow regardless of the implementation. Obviously JS,HTML, CSS will play a role ;-) but everything else should be open and choosen based on the requirement.
@jdubray just to tell you I'm quickly of if we go down to code samples
Jean-Jacques Dubray
@jdubray
Oct 31 2017 14:16
@hwinkel no problem, happy to answer your questions
@foxdonut thanks!