These are chat archives for jdubray/sam

25th
Jun 2016
Fred Daoud
@foxdonut
Jun 25 2016 03:45 UTC
but what I posted is not DOM manipulation. in nap() it is triggering an action that mutates the application state. the input field being cleared is a result of V = f(M) because actions.clearEdit presents data to the model which then mutates the state so that the data used to populate the input field is now blank.
the view remains driven by the model. moreover, mutating the model to clear the data for the input field after saving a todo, should not be done directly in model.present (i.e. both mutations in one "step"), because that limits the reusability of the "saveTodo" step.
Jean-Jacques Dubray
@jdubray
Jun 25 2016 06:02 UTC

I see,

both mutations in one "step"

I would say it depends, that's the benefit of the single state tree, you can carry multiple mutation as a unit-of-work. Nothing prevents you to create another unit of work. I do favor present methods that locally complete all mutations. A "step" (action/model/state) should be used meaningfully (e.g. in the rocket example, nap invokes the launch action when the counter is zero). It's really about automatic state transition, things that users (and therefore the view) can't do, because they are automatic, the model can't do, because that's an action.

Fred Daoud
@foxdonut
Jun 25 2016 10:50 UTC
I understand. I will experiment with that. Thanks JJ!
As for focus, you're right, it's tricky. With React, you can use autoFocus, and libraries like Snabbdom and Mithril have hooks:
Jean-Jacques Dubray
@jdubray
Jun 25 2016 10:59 UTC
@foxdonut you have to be opinionated as to whether you think in terms of updates (say like Elm) or state transitions. I don't like "updates", that's not the right unit of work.
I also favor minimalist component lifecycle (say unlike React), the big mistake would be to trying to funnel an application state transition in a component lifecycle.
That's why I advise any to be very careful about what your programing model prescribes. Sometime you want it very open, leaving the decision to the developer, sometimes, you want it to be really rigid, because it has huge implications on the maintainability of the code base.
Fred Daoud
@foxdonut
Jun 25 2016 11:47 UTC
I completely agree about minimalist component lifecycle. the view should, as much as possible, be determined by the model. The focus problem is a rare case where you need something from the markup.
Jean-Jacques Dubray
@jdubray
Jun 25 2016 11:48 UTC
yes
Fred Daoud
@foxdonut
Jun 25 2016 11:48 UTC
As for "update" vs "state transition", do you mean in terms of naming? I do prefer "state transition". In my code and examples, "update" is the same, in terms of code. As I've said earlier, naming is hard, and I am open to making changes.
Jean-Jacques Dubray
@jdubray
Jun 25 2016 11:50 UTC
I don't care so much about names as we agree on semantics. I was concerned that resetting an input field does not look like a state transition.
Fred Daoud
@foxdonut
Jun 25 2016 11:51 UTC
It is, but let me know if there is any way I can make that clearer.
Jean-Jacques Dubray
@jdubray
Jun 25 2016 13:49 UTC
@foxdonut see how semantics are important? people see JSX as ("basically") templates
Fred Daoud
@foxdonut
Jun 25 2016 13:56 UTC
yeah, that's a mistake on their part.
So, again, I agree with you... how can I make the state transition clearer?
Jean-Jacques Dubray
@jdubray
Jun 25 2016 14:01 UTC

Not sure, because in the end developers choose to code what they want, possible strategies to consider:
1/ offer both concepts (individual updates, units of work/state transition)
2/ make it more expansive (in the call signature) so people don't feel they could use it as a setter
3/ ??

for instance actions.clearEdit(); looks too much like a function call/setter. Actions should always have an argument. Consider a dispatcher pattern to enforce that rule.

actions are merely mediating an event to mutation (an event being the occurrence of a state), so the argument of an action should be the event that triggered it.
The mistake has been, for decades, that the handler didn't have a clear separation between proposers / acceptors / learners.
It's a bit hard to enforce semantics, the clearer they are the more natural they feel to the developer.
Fred Daoud
@foxdonut
Jun 25 2016 14:10 UTC
Sounds good! Thank you JJ
Jean-Jacques Dubray
@jdubray
Jun 25 2016 14:15 UTC
For instance, the part that I feel Elm is really missing is that commands seem to be issued individually, even though it seems you prepare them as a task (I may be wrong). That's the kind of semantics that would lead developers to believe that a command is a setter and it's ok to set the values of model properties as you please -> anti-pattern (again please correct me if I am wrong).
Jean-Jacques Dubray
@jdubray
Jun 25 2016 14:43 UTC
Anyone has tried the Angular Mobile Toolkit? https://mobile.angular.io/
If yes, what do you think?
Jean-Jacques Dubray
@jdubray
Jun 25 2016 14:52 UTC
Wow, outcome is no longer a dirty word in Software Engineering: https://twitter.com/martinfowler/status/738001337011572736
Jean-Jacques Dubray
@jdubray
Jun 25 2016 19:50 UTC

Apologies for bragging, I spent a lot of energy in the work I published over the last 15 years. This is the email I received today:

I saw that you have RSVPed for SeattleJS Hack night on this coming Monday. I was wondering if you are committed to attend? I would really like to meet you and I was frankly shocked to see your name on the roster because I respect your work on SAM architecture. I read over the website and have been studying for months now whenever I find the time. I live in the east side so it's quite a Lyft/Uber ride and commitment to go to the Metrix location in Broadway. Please let me know if you are going or might possibly not attend.

This kind of emails makes it all worthwhile.
devin ivy
@devinivy
Jun 25 2016 21:48 UTC
:)