These are chat archives for jdubray/sam

9th
Jun 2017
Johan Alkstål
@johanalkstal
Jun 09 2017 16:28
Simple question but... any tips on naming proposals? :D
Daniel Neveux
@dagatsoin
Jun 09 2017 16:30
With typescript I use some IPresentUserData to type my data.
Johan Alkstål
@johanalkstal
Jun 09 2017 16:31
You use a "Present" prefix?
Daniel Neveux
@dagatsoin
Jun 09 2017 16:31
But I love to use interface to say IDoSomething. A lot...
For the interface yes. And my variable is always named data.
Jean-Jacques Dubray
@jdubray
Jun 09 2017 16:38
@johanalkstal It's very important to keep the many-to-many relationship between actions and acceptors (one proposal can trigger several acceptors). People have often expressed they don't like it, but I think that's an essential part of the pattern's structure. What works well for me is simply to pass a data structure and have the acceptors check for the presence of data elements in the proposal.
Johan Alkstål
@johanalkstal
Jun 09 2017 16:39
Okay. So basically the Model checks proposals for properties found on the Model, and based on the combination you assume something specific is meant to happen?
Or did I missunderstand?
Jean-Jacques Dubray
@jdubray
Jun 09 2017 16:43
yes, correct.
Johan Alkstål
@johanalkstal
Jun 09 2017 16:45
Hmm ok.
Jean-Jacques Dubray
@jdubray
Jun 09 2017 16:46
When the operation is "additive" (counter++, newUser, ...) it's more a command, otherwise when it's an assignment it's best to stick to simple property updates. The difference between actions and model is that the roles of the actions is to validate (event), transform and enrich (the event), the role of the model is to make sure the mutation respects the integrity of the model.
The action should not know much about the model elements, it's really focused on the event.
Johan Alkstål
@johanalkstal
Jun 09 2017 16:47
So the Model doesn't decide what the next state should be, it just validates the data structure it receives. The action is responsible for the structure of the proposal.

A simple example,
a form is invalid and a message needs to be displayed.

In that case, the Action decides what the message should be, the Model only makes sure it's a string?

Jean-Jacques Dubray
@jdubray
Jun 09 2017 16:49
The action decides about the proposal, the model has no idea where that proposal came from (which event is responsible for it). Many actions can point to the same acceptor, but it is as essential for modularity that a proposal element can trigger multiple acceptors. So it's not a simple call between the action and the model. The action does not know what will happen.
It can be either way in that case. The action can report an error, but in some cases, the error could be detected by the model.
Otherwise yes, the model will have an error element and when it is present, the state/view function will render accordingly.
For instance I often use a "formField" function that takes as an input a series of parameters, including any error condition. With the css I use, the error is clearly marked (has-error) and the error message is displayed in the <span> element below:
      <div class="form-group ${(hasProperty && hasError) ? `has-error` : ''} ${params.icon ? `has-feedback` : ''}">
...

          ${ (hasProperty && hasError) ? `<span class="help-block no-margin">${loc(params.errorMessage || "")}</span>` : ''}
     </div>
Jean-Jacques Dubray
@jdubray
Jun 09 2017 16:55
It works beautifully, my forms are very simple function calls field = f(props).
Johan Alkstål
@johanalkstal
Jun 09 2017 16:56
Thanks. I'll ponder some more on what's been said :)
Jean-Jacques Dubray
@jdubray
Jun 09 2017 17:00
This is the template I am working from: http://bootstrap.gallery/arise/pearl/form-inputs.html
This is the original HTML snippet I parameterized:
<div class="form-group has-error has-feedback no-margin">
    <label for="simpleInput" class="control-label">Input with info</label>
    <input type="text" class="form-control" id="inputError2" placeholder="Input with help text"> 
    <span class="help-block no-margin">A block of help text that breaks onto a new line and may..</span>
</div>
Johan Alkstål
@johanalkstal
Jun 09 2017 19:11

"when you implement a "change password" action, the action will check if the password is valid in the context of the request, but the model might enforce additional integrity rules, such that you cannot use a password that matches any of your last three passwords."

This is something I think I will struggle with for a bit.
For instance, the action makes sure the password is of a correct complexity (one kind of validation), and then the model makes sure it's not the same as previous passwords (another kind of validation). Immediately understanding what kind of validation is appropriate where.

Jean-Jacques Dubray
@jdubray
Jun 09 2017 19:16
yes exactly
A call to an API within the model should be blocking (you cannot process another proposal), which would be ok here. In general enrichment (such as fetching the list of previous passwords) and then include the new password and the list of previous passwords in the proposal to let the model decide what should happen. If the model accepts the proposal I would recommend you call the API to update the password from the model and then render the state representation once the operation has succeeded.
Jean-Jacques Dubray
@jdubray
Jun 09 2017 21:51

@johanalkstal just to be clear rules may depend on your context but in general I apply the following:
Action

  • event validation
  • event transformation (into proposal)
  • proposal enrichment

Model

  • data integrity
  • data mutation

The case that you are bringing up can be viewed as proposal enrichment or data integrity. It seems to be that calling the API and getting the last passwords is an enrichment, but making the decision as to how different it has to be from how many passwords would be decided by the model.

Johan Alkstål
@johanalkstal
Jun 09 2017 21:52
:+1:
Marcus Feitoza
@mfeitoza
Jun 09 2017 22:29
If the front-end has the complete SAM pattern, whose responsibility is to update a server resource? Is from action or model? Or depends?
I think is from action, but now I stayed a little confuse.
Jean-Jacques Dubray
@jdubray
Jun 09 2017 22:33
There are two points of view:
1/ the model should be responsible for mutation -> hence, persistence
2/ a persistence action should be triggered via nap (Elm, Redux...)
I like 1/ a lot better. I find 2/ introduces lots of boilerplate code for no value
Michael Terry
@formido
Jun 09 2017 22:33
model is in charge of persistence
Jean-Jacques Dubray
@jdubray
Jun 09 2017 22:33
:+1:
Marcus Feitoza
@mfeitoza
Jun 09 2017 22:36
Thank you.
Marcus Feitoza
@mfeitoza
Jun 09 2017 23:51
How are you dealing with "async" like Promises?
The model receive a proposal and call a fetch() for example...
The flow of app will continue and set the model to waiting status, and we need to present again a proposal to model after fetch complete?