These are chat archives for jdubray/sam

22nd
Mar 2018
david kaye
@dfkaye_twitter
Mar 22 2018 06:39
Two questions. Take the next week off to think about them.
  1. If view is a function of the model, what do I need state for?
  2. What is the difference between object, data, and state?
Victor Noël
@victornoel
Mar 22 2018 06:46
at least for 2: object is about behaviour (if you do "real" OO à la smalltalk and co, not "data decorated with methods" OO) while data is well... data :). In this context state is... something else :)
For 1, that's a good question :)
Victor Noël
@victornoel
Mar 22 2018 07:36
well, for 1, actually, when we say "view is a function of the mode", we are talking about the model as a datastructure, not the model as the engine that maintains this datastructure. When we say state, there is the state as a behaviour to apply on the model, and there is state representation which is the datastructure: in this context, the state's role is to decide which function to invoke on the model to produce the view (or in more reactive architecture, to decide to communicate the new state representation to the view or not) and also for triggering new actions based on the current state of the application.
@dfkaye_twitter To me, those questions stems from a confusion between data and behaviour (or at least, I think it would be a good idea to reformulate them by making it explicit)
Jean-Jacques Dubray
@jdubray
Mar 22 2018 13:35
@dfkaye_twitter V = f(M) is kind of the historical view of React in the context of M-VC, it's not literal.
devin ivy
@devinivy
Mar 22 2018 13:38

If view is a function of the model, what do I need state for?

i find this one to be really important. it's so that your model and your views aren't coupled!

Jean-Jacques Dubray
@jdubray
Mar 22 2018 13:39
@victornoel precisely, we need to make a clear delineation between the application state as a list of property values (TLA+), the rules of mutation (next-state-relation), the computation of the control state (~state representation) as a result from the mutation and ultimately the next-action-predicate. It's not helpful to put all this in the same bag.
@devinivy :+1:
devin ivy
@devinivy
Mar 22 2018 13:40
adding a state representation to adapt between your model and views allows your models and views to do what they're best at, which is so important because they both carry huge complexities on their own, even before you try to get them talking to each other.
Jean-Jacques Dubray
@jdubray
Mar 22 2018 13:40
:+1:
It's already complex enough when you separate all these concerns, I cannot imagine writing code without deliberately doing it.
devin ivy
@devinivy
Mar 22 2018 13:42
i can imagine coupling the two because i have done it before, on my first ever single page app. it hurt!
Jean-Jacques Dubray
@jdubray
Mar 22 2018 13:43
Not to mention maintaining that code, coming back 6 months later to implement a new feature, or fix an edge case defect.
devin ivy
@devinivy
Mar 22 2018 13:47
and i find it really critical to have the same factoring in the other direction. even actions-as-proposals aside. inside my views it helps to think structurally about actions. inside a view i try really hard even just name action hooks/props without thinking about the entire application. for example, in a simple counter example the view would have onClickPlus (describe what the user did) not onIncrement(infer what the user intends to do in the app).
sometimes just naming things like this can really help keep cognitive load lower, and is fundamental to further separation of concerns.
then somewhere you just wire it up! onClickPlus: increment
that "somewhere" i think is analogous to state representation but for the other side of the reactive loop
Jean-Jacques Dubray
@jdubray
Mar 22 2018 13:50
:+1: music to my hears...
devin ivy
@devinivy
Mar 22 2018 13:52
:smile: :beers: cheers!
and going past that is where you move from what's just good factoring into SAM's semantics— conceptualizing those actions as proposals, for example.
Jean-Jacques Dubray
@jdubray
Mar 22 2018 13:56
The keystone of the pattern is the temporal structure which allows to have a single place to reason about where you are temporally and what needs to happen next. If I needed to achieve the same result for FSMs or IFTTTs I'd be lost after just a couple of actions. It's hard to describe without experiencing it and then imagining what it would look like as an FSM for instance, then you understand and you never go back.
Fred Daoud
@foxdonut
Mar 22 2018 14:04
@devinivy very well said. you nailed it! :100:
devin ivy
@devinivy
Mar 22 2018 14:07
:pray: :relaxed: :beers: !
Victor Noël
@victornoel
Mar 22 2018 14:53
@jdubray "a single place to reason about where you are temporally and what needs to happen next", do you mean the state?
Jean-Jacques Dubray
@jdubray
Mar 22 2018 15:59
Yes, the "state" function allows you to reason about the current state of the app/system at a very precise point (after the mutation is complete) and take appropriate (next) action(s) including rendering.
I find this priceless compared to any other approach to state management I tried before.
Victor Noël
@victornoel
Mar 22 2018 16:08
yep, thx for the clarification