These are chat archives for jdubray/sam

2nd
Feb 2018
Scott Conklin
@srconklin
Feb 02 2018 16:21

As I get into a real world application using SAM, I find myself rarely doing significant processing in my model.present function. I always just accept the incoming data unchallenged from some action and assign it to the model. In my state.representation function I then just check for various flags that will have been set and either repaint snippets of html or refresh the whole app. I notice this comment in some of the simple skeleton samples : " //Logic that accepts or rejects the proposed values"...

I have a form that needs to validate that the user has agreed to the terms and conditions on clicking of a submit button.
My approach is to fire an action on click of the button; present the form data to the model, assign the data to the model , check for missing or unassigned value in the model (that the checkbox would have represented) in the state machine; re-render a show an error message; turn the model flag off in NAP().
does this sound like an ok way to handle the process?
Should I be making use of the model.present function to perform data validation?
Should i being doing validation differently?

devin ivy
@devinivy
Feb 02 2018 16:24
@srconklin i'm really interested in validation as it pertains to SAM!
it's tricky because users should be able to type invalid values
but in my opinion the model should not accept them as a part of domain state
so in my opinion you need two bits of state– the UI state of the form (may contain invalid values) and the domain state (may not contain invalid values). then you actually get basic validation for free because if those two don't match then the typed value is invalid :D
here's a lib i wrote to help manage this in react
Scott Conklin
@srconklin
Feb 02 2018 16:27
yes me too... true about not accepting them, but what really is there to say about a domain state in terms of whether a user checked a box or not.. i have my model just simply having a flag isTandC
devin ivy
@devinivy
Feb 02 2018 16:27
that seems natural :)
Scott Conklin
@srconklin
Feb 02 2018 16:27
@devinivy thanks will look at the lib
devin ivy
@devinivy
Feb 02 2018 16:28
yes i see what you mean– sometimes forms/fields don't really have much to do with domain state
Scott Conklin
@srconklin
Feb 02 2018 16:30
@devinivy yes, I think that is true.. however, I like your approach of keeping a form state and domain state and comparing the two...
if they fail to validate (in model.present? I assume) How do you react? You need to rerender with an error message... So how would that differ from the approach that I am taking?
devin ivy
@devinivy
Feb 02 2018 16:33
well, for one you get some free validation
if you have two values (UI and domain state) and they don't match
then you're not in a valid state!
as for figuring-out why they don't match, i think usually it makes sense to live near UI state
once the UI sees that the value is bad it tries to figure-out why
and display whatever error message
but i think that approach is certainly up for debate :)
Scott Conklin
@srconklin
Feb 02 2018 16:36
@devinivy yes i see. thanks... I think I am coming out that I am still not 100% clear where and exactly how to implement data validation in the reactive loop..
Jean-Jacques Dubray
@jdubray
Feb 02 2018 17:01

@srconklin there are two types of validation:

  • activity level validation
  • domain validation

You should implement activity level validations in the action and domain validations in the model. Encapsulating mutation in the model also helps with concurrency, especially in the case when the action would enrich the user event with an API query.

Domain integrity should be the rules that work across all activities, while Activity level rules migh change from one activity to the next (or the type of user, say like bronze, silver, gold...)
When the activity and the domain are one and the same or you don't enrich the proposal with API calls, then yes, I agree, you may end up feeling that's a bit overkill.
@devinivy when an error occurs, the same division of responsibility would occur, activity level errors would be part of the proposal. When domain integrity violations occur, the model should be responsbile for raising the corresponding flag. I would not go as far as NAP for that.
The state function would then see the error condition and condition the view appropriately.
Jean-Jacques Dubray
@jdubray
Feb 02 2018 17:08
This has worked well for me with complex form, the template literal would simply look for field level errors and render each field accordingly. Let me know if you need to see some code, I am happy to write up something over the week-end.
Fred Daoud
@foxdonut
Feb 02 2018 17:55
@srconklin I have had good success with @devinivy 's approach as well, namely, what he said: two bits of state– the UI state of the form (may contain invalid values) and the domain state (may not contain invalid values).
@jdubray raises a good point as well, actions can validate before proposing (is that user allowed to do this, for example), vs domain-level integrity validation in the model.
Scott Conklin
@srconklin
Feb 02 2018 19:57
@foxdonut thanks
Scott Conklin
@srconklin
Feb 02 2018 20:03
@jdubray thanks. So in the case of of an activity level validation which you are saying needs to be done in the action... don't I still have to let control flow through to model.present --> state.render --> staterepresentation -> to view.display so that I can show an error message about invalid form state? Or are you suggesting another way to update the UI to show the user the invalid form state?
@jdubray >> Let me know if you need to see some code, I am happy to write up something over the week-end.
yes. I think I would.
Jean-Jacques Dubray
@jdubray
Feb 02 2018 20:49
Yes absolutely, the flow will remain the same, the action will propose an error. The model could overwrite it with default or personalized values then the state will render.
Scott Conklin
@srconklin
Feb 02 2018 20:50
@jdubray good! thanks.. that is what I thought.
Jean-Jacques Dubray
@jdubray
Feb 02 2018 20:53
You may also consider omnichannel solutions (mobile and web) that have slightly different actions (because the form is split in different screens). Overall activity/domain is a very healthy separation of concern.