These are chat archives for jdubray/sam

14th
Feb 2016
Michael Solovyov
@msolovyov
Feb 14 2016 15:19
@jdubray I took a stab at a SAM rocket implementation with vue.js http://jsbin.com/hicaca/edit?html,js,output does this adhere properly to SAM?
Jean-Jacques Dubray
@jdubray
Feb 14 2016 16:25
There is only one aspect that doesn't, actions are not supposed to change the model directly but rather to present new values to the model, so this kind of statement inside the action is not possible:
rocket.model.started = true;
it should be:
data.started = true;
rocket.model.present(data) ;
and then in the present method:
if (ok) {
       rocket.model.started = data.started;
}
Michael Solovyov
@msolovyov
Feb 14 2016 16:29
That seems redundant, what's the advantage of adding an inbetween method?
Jean-Jacques Dubray
@jdubray
Feb 14 2016 16:32
It decouples the what the actions do from the model, this is a very important point. Actions become highly reusable across models. You can test them independently.
Jean-Jacques Dubray
@jdubray
Feb 14 2016 16:38

The fundamental reason though is that you rarely make the decision of changing some property values, just on these property values. So regardless where you will put this code, you will alway have these two aspects:

if (ok(model)) {
      model.a = newA ;
      model.b = newB ;
     ...
}

Think about the "increment" or "decrement" action, why would the action know anything about what to do when the counter reaches 0? Actually, the model doesn't even know either. It is the role of the nap() function.
But why the action should know about rules such like the counter must be > 0?

SAM decomposes these 3 steps:
  • compute the proposed changes (action)
  • apply changes (model)
  • as a result:
    -- render the view
    -- compute next action
    -- execute it
Jean-Jacques Dubray
@jdubray
Feb 14 2016 16:44
For instance redux couples step 1 and 2 in the reducer. IMHO, not the best choice, by far.
I am actually surprised that no one in the Redux camp seems to care about that coupling
I am also surprised they don't want to talk about nap()
It's actually fascinating to think that as software engineers they would not want to engage in a "coupling discussion".
Michael Solovyov
@msolovyov
Feb 14 2016 16:53
Thanks, I'll give those modifications a try. So where do you see the interaction happening with an external api, thus achieving decoupling ui from api? In the nap or in the actions?
I'm guessing the actions load in from api into data object, then call the present which uses that data into the ui?
I mean into the model then into the ui
Jean-Jacques Dubray
@jdubray
Feb 14 2016 16:58
There are two kinds of APIs:
  • 3rd party APIs like getPostalAddress({street: , city: , zip:})
  • CRUD APIS
3rd party APIs should be called in the actions since their purpose is to compute the dataset to be presented to the model
the CRUD methods should be below the model
With SAM, all the view sees are queries and commands that much whatever it needs.
The big different though is that there is no "response", at the end of the reactive loop a new view is computed.
at least logically computed
There is never a case where the view (or the controller) is trying to get data and bind it to a template, or directly tell the model what to CRUD. The model is solely responsible for persisting itself
Michael Solovyov
@msolovyov
Feb 14 2016 17:03
as for the redux camp comment, if you don't care about reusing actions then that decoupling adds unnecessary complexity.
Jean-Jacques Dubray
@jdubray
Feb 14 2016 17:04
You can think of it that way, but the reducer looks like a big ball of mud. Good luck in testing/debugging/maintaining that kind of code
decoupling is not just about reusing, there are concerns like cohesion and coupling that need to be taken into account and for me at least, actions should never be coupled to the model.
Michael Solovyov
@msolovyov
Feb 14 2016 17:09
earlier you said "Think about the "increment" or "decrement" action, why would the action know anything about what to do when the counter reaches 0? " but why would those actions then know about the present method? I was looking at this diagram http://cdn.infoq.com/statics_s2_20160209-0057/resource/articles/no-more-mvc-frameworks/en/resources/fig5.jpg when I was building that example, the action influencing the model
Jean-Jacques Dubray
@jdubray
Feb 14 2016 17:13
that's just "wiring", you need to form the reactive loop
you can use any form of wiring, pub/sub, observables,
Granted that's not the best form of wiring, but it has the merit of showing the reactive flow
and emphasizing that the flow is unidirectional, the action does not wait on a response from the model
I could implement that in MVC too where the controller is A + S:
the controller code would look like this:
outputs = A(inputs)
model = model.update(outputs)
nextView = S(model)
action = nap(model)
action(model)
Jean-Jacques Dubray
@jdubray
Feb 14 2016 17:19
That's just another form of "wiring" (orchestration)
Michael Solovyov
@msolovyov
Feb 14 2016 17:20
gotcha
that example really clears it up
Jean-Jacques Dubray
@jdubray
Feb 14 2016 17:22
The problem with MVC is now you have coupled all this code in one method, it is (nicely) broken down in my pseudo code, but when you look at how people write the controller code, it is again a big ball of mud
I didn't invent this factoring, it comes directly from TLA+ (temporal logic of action)
It is a bunch of if-then-else that become quickly impossible to maintain
The beauty is that things like databinding or graphQL become redundant.
If you watch that video about building a React app, you don't get this feeling that they really know what they are doing: https://www.youtube.com/watch?v=mubbsC-zIew
React has no advantage, not even zero, they are undefined
Jean-Jacques Dubray
@jdubray
Feb 14 2016 17:27
Just try this ToDo app from ngrx/core, it takes 10 min to install on your Mac, really?
SAM gives you React + Redux + Relay without any framework, for free, in plain and simple JavaScript, and you have no need for GraphQL.
Your app has to be very complex to require something like the virtual-dom. In most cases you don't need it
These frameworks are out of control
Jean-Jacques Dubray
@jdubray
Feb 14 2016 18:20
A new sample, the Item List: https://bitbucket.org/snippets/jdubray/zr9r6
To be compared with Redux and ngrx/core samples
Michael Solovyov
@msolovyov
Feb 14 2016 22:25
I have update my vue.js sam rocket with your advice. most of the functionality is the same as your pure js example except the view code is a lot cleaner with the help of vue.js http://codepen.io/msolovyov/pen/EPMxOo?editors=1010
Michael Solovyov
@msolovyov
Feb 14 2016 23:14
Do you see any disadvantages/mistake?
Michael Solovyov
@msolovyov
Feb 14 2016 23:21
I'm actually a little stunned. This pattern seems to make a lot of frameworks redundant.