These are chat archives for jdubray/sam

26th
Jul 2016
Vincent Jo
@chiwoojo
Jul 26 2016 03:28
hey JJ, I've thought about how much logic there should be in a component vs. in the reactive loop today
but I'm still fighting over the confusion of having too much vs. too little in the component. How would one draw the line?
what properties should the model absolutely keep? and what properties model should certainly not keep?
Jean-Jacques Dubray
@jdubray
Jul 26 2016 05:13
The only logic / state in the component should be component centric and still remain if this component was used by a different app.
All the app logic should be in the SAM loop because one day you'll want to change the Web framework you are using (Angular3, ...)

For instance you can see in the Angular2 sample that I started to work on that a typical design would strongly couple the component to:

  • back-end:
    this.todoList = this._todoService.getTodoList();
  • app logic and model:

    addToDoItem($event) {
    
      if (($event.which === 1 || $event.which === 13) && this.newTodoText.trim() != '') {
    
        this.todoList.unshift({
          text: this.newTodoText,
          color: this._getRandomColor(),
        });
        this.newTodoText = '';
      }
    }
The component display "state" could include whether the data is sorted and in which order. That is border line with application state, but for the sake of argument, it would fit into the component.
A component should only:
  • expose props -> new props should trigger a redisplay
  • publish events that represent the user intent (e.g. to a dispatcher)
That kind of component would be highly reusable across applications
Jean-Jacques Dubray
@jdubray
Jul 26 2016 05:19
hope that helps
Jean-Jacques Dubray
@jdubray
Jul 26 2016 05:29
Angular2 goes one step further: it "natively" couples view components together because of the Parent/Child relationship it artificially relies on (what were they thinking?) to update props and catch events.
devin ivy
@devinivy
Jul 26 2016 12:32
@chiwoojo one example i like to think about to help answer that question is this: imagine a text field that's tied to the model, but the text field should allow any value that the user types, even if that value isn't valid. if the value is invalid (doesn't match the model) it should show an indication of error.
in that case the text field component needs both the model's value and its own internal value.
(incidentally, this is also essentially how i think forms should work in SAM and flux)
Fred Daoud
@foxdonut
Jul 26 2016 13:41
@devinivy :thumbsup:
Vincent Jo
@chiwoojo
Jul 26 2016 14:57
@devinivy but if the component knows about the model, that doesn't conform to sam standards isn't it?
in regards to form validation...
that's a very good example I think makes me think that simple validation (check if it's a number or not, character length restrictions) could live in the component, and when a user clicks on the 'submit' or whatever the reactive loop can start to check additional things
where would the component logic be most appropriate in SAM?
I'm currently using util functions hook up event handlers but I wonder if it's better to store this logic somewhere else
like a componentlogic.js or something?
Vincent Jo
@chiwoojo
Jul 26 2016 15:02
or inside the component something like this?
   somefunctionToCheckSomething();
    ready(model) {
        return (`
            <a class="btn btn-primary" onClick=${intents.enter} role="button">
                ${model.reqToEnterMsg}
            </a>
        `);
    },
devin ivy
@devinivy
Jul 26 2016 15:04
the component doesn't necessarily know about the model. but effectively it is using state derived from the model. and the real validation occurs in the model.
the component can do some basic validation i suppose, but really i think you want the validation logic to live in the model.
during the "acceptance" phase
Vincent Jo
@chiwoojo
Jul 26 2016 15:06
yea I agree the true validation should occur in the model.. I remember reading this somewhere in sam.js.org
or like a double check
devin ivy
@devinivy
Jul 26 2016 15:08
a date input component might validate that the user offered a valid date. but the model might know more info, like the fact that the date needs to be during the winter time (for whatever business reason).
or that the date needs to be on the weekend.
Vincent Jo
@chiwoojo
Jul 26 2016 15:25
yea, that sounds good thanks
Fred Daoud
@foxdonut
Jul 26 2016 15:26
right, common model business rules are that a date needs to be in the past (e.g. date of birth) or in the future (appointment request date)
Vincent Jo
@chiwoojo
Jul 26 2016 15:32
I think it would be great if sam had a prescribed way of hooking up component logic to the view
I will experiment with different ways tomorrow... I think it can be done in many different ways..
Jean-Jacques Dubray
@jdubray
Jul 26 2016 19:21
@chiwoojo @devinivy @foxdonut If you want the component to enforce business rules, such as "start date < date < end date" you still have the option to pass start date and end date from the model to the component. That would not be a violation of the the decoupling between the component and the model. That is just a "validating component".
What is more concerning is the step concept, if you are guaranteed that no other actions will be processed, then it's ok, to have a mini-reactive loop inside the component (for instance marking validation errors), but I personally dislike it. I know it looks like a bit of overhead to go back to the model, but in the long run it's a better approach because other parts of the application may be interested in this information.
Jean-Jacques Dubray
@jdubray
Jul 26 2016 19:28
The problem comes when you have to deal with concurrency, a network event triggers an action while you are filling out the form, or the user interacts with some other parts of the GUI. You are almost always better off to keep "application state" in the model as you can.
Jean-Jacques Dubray
@jdubray
Jul 26 2016 19:34
Take another example: say, a component can have some fields that are "editable". The component could manage this "editable" state since the model should really be notified of the changes when the user exit the field or submits the changes. You could argue that the "editable" state is throw away, but if you "stepped" away (as in SAM step) and needed to come back to that component, then you would expect the component to display as it was before you left. I believe V = f(M) is always preferable.
For business logic, another option would be to pass functions to the component from the state representation. SR can be HTML, JSON or Functions.
devin ivy
@devinivy
Jul 26 2016 20:43
the thing is, placing a piece of component state in the app state can totally be done as needed.
at least in this case where the state we're talking about may be highly specialized.