These are chat archives for jdubray/sam

Feb 2017
Rodrigo Carranza
Feb 03 2017 00:06 UTC
But I have this problem, I have a Canvas Element and It would be expensive to create a Canvas Element every time, I could create forms or other elements but Canvas is a really expensive element due to rendering contexts.
Jean-Jacques Dubray
Feb 03 2017 00:09 UTC
Did you see how I implemented that sample (with Canvas)?
Would that work for you? I only create it once.

Once of the elements of the state representation is a function

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

(draw returns a function that gets executed when the state representation is displayed)

I was just exploring, not sure that's how it should be done
Rodrigo Carranza
Feb 03 2017 01:46 UTC
I was always assuming that the view had to be entirely generated by the state, but now I know I could just externaly manage an already existing view.
That was not clear for me 😅
But wouldn't using ES6 templates make the client open to html injection?
Jean-Jacques Dubray
Feb 03 2017 02:27 UTC
I am not a specialist, but I don't think they are any less safe than a framework. All the content of the state representation can be escaped, you actually have a central place to do that prior to be injected in the template literals.
Radosavljevic Slobodan
Feb 03 2017 20:06 UTC

Hi I've just started reading on SAM architecture. I like what React has been doing, but everything is actually based on a hunch to be honest, so I'll follow Kyle Simpsons advice and diversify my sources :). It's a long road, but everything begins with a first step.

I have a question;
what are your thinkings on redux-logic?

Best regards.

Jean-Jacques Dubray
Feb 03 2017 22:53 UTC
@radosavljevic welcome, "on a hunch" indeed. I heard several people on this list liking redux-logic @jeffbski I believed borrowed a thing or two from SAM.
Here are my arguments (apologies for the repeat) against the Redux/Elm programming model.

The root of the problem comes from the fact that for decades, we have been writing code relyign on three approximations:

  • actions can update the application state
  • assignments are equivalent to mutation
  • there is no need to define what a programming step is with precision
    (e.g. is "a = b + c" a step? or is it 3 steps: read b,c; compute b+c; assign result to a;

The typical manifestation of these approximation is the "event handler" which will make a bunch of assignments and DOM manipulations, before returning control to the event loop.

These approximations no longer hold in the kind of software we are building these days. Redux and Elm aim at addressing these approximations in their own way:

  • an action is a data structure (not a function)
  • there is one "big" assignment (due to immutability)
  • the "step" is a function

This is possibly the worst way immaginable to fix these three approximations, though on paper it looks like you are addressing them somehow.
In SAM actions propose updates to the model, model is mutable but controls 100% of the mutation, no rogue assignments, a step is clearly defined as action->model->state representation