These are chat archives for jdubray/sam

13th
Jun 2016
weepy
@weepy
Jun 13 2016 13:23
But you can have a state tree and bind your ui to changes in that.
Whatever mutates the state tree can be separate
Edward Mulraney
@edmulraney
Jun 13 2016 13:28
I like this paragraph by Dan Abramov: "The whole point of Flux/Redux is to decouple actions and reducers. There may be many independent reducers handling one action, and there may be many independent actions handled by one reducer. This is what makes Flux/Redux scale because big teams can work on overlapping features without constant merge conflicts, as state mutation logic is kept separate even if it is caused by the same actions."
@jdubray it sounds weird coupling the mutation ("what happened") with the proposition ("what I want to happen"). Is this what you're saying SAM/PAL does?
Edward Mulraney
@edmulraney
Jun 13 2016 13:34
propose -> dispatch -> receive result -> mutate piece of state to result
devin ivy
@devinivy
Jun 13 2016 13:37
well, in SAM the "action" is more like an action-creator in redux. in SAM the proposal is ultimately the result of the action (which is generally a function– not a serializable POJO).
Jean-Jacques Dubray
@jdubray
Jun 13 2016 14:27

The semantics are event/intent/actions/mutation, it makes no sense to drive mutation from an event like in Redux. The user clicks on a button, the intent is to submit the form, the actions prepares the data, the model mutates the application state with the action's proposal.
The problem in Redux is to have two semantics for actions (event and action-creator). Are we saying that whatever comes from the view is ready to be processed? without validation or enrichment?

The whole point of Flux/Redux is to decouple actions and reducers.

Redux "actions" are not actions, the true actions are coupled to the model deep inside the reducer

@edmulraney

("what happened") with the proposition ("what I want to happen"). Is this what you're saying SAM/PAL does?

why is it weird? how would the event control the mutation? a la redux?
{ type: 'SET_VISIBILITY_FILTER', filter: 'SHOW_ALL' }

that is really weird, makes no sense at all.
devin ivy
@devinivy
Jun 13 2016 14:29
is there a problem creating reusable actions, @jdubray, if the actions have to understand the model?
Jean-Jacques Dubray
@jdubray
Jun 13 2016 14:30
actions are a form of adapters between the view and the model, while the state/learners are the adapters between the mode and the view
you can reuse actions across models with simple function composition
my_model_dependent_action(my_reusable_action(data))
devin ivy
@devinivy
Jun 13 2016 14:31
gotchya!
Jean-Jacques Dubray
@jdubray
Jun 13 2016 14:31
TLA+ action definition is very simple and powerful:
data' = A(data)
devin ivy
@devinivy
Jun 13 2016 14:32
makes sense :)
Jean-Jacques Dubray
@jdubray
Jun 13 2016 14:33
That kind of definition works like a data pipeline, so it's very easy to factor actions in independent parts.
By separating action and model you can also factor application specific logic in the action and more enterprisey business logic in the model
The example I often use is that you create a new product that you want to roll out in a territory, you don't want to write this kind of logic in the model, the action will make sure that only customers with addresses in that territory can sign up for the new product. The model remains unchanged and handles addresses from all countries/territories.
conversely you were doing business in one country and you just updated your model to do business in additional countries. You can update existing actions to pass default values for addresses without a country so that the model doesn't know about that "hack".
Jean-Jacques Dubray
@jdubray
Jun 13 2016 14:39
This separation proposers/acceptors is very healthy, I can only see benefits from it, I certainly don't understand why would anyone push back. The rule is very easy, the action presents the values you want the model to mutate too, the model owns the business logic to accept these values, it knows nothing how they were computed or where they are coming from (in general).
Please not that Dan does not even talk about effects in his "Redux is simple" intro. That's cheap.
Jean-Jacques Dubray
@jdubray
Jun 13 2016 14:45
@devinivy I would expect SAM's actions to be currying heaven
devin ivy
@devinivy
Jun 13 2016 14:46
i can see that!
what do you think about proposals being typed, i.e. with union-types?
Jean-Jacques Dubray
@jdubray
Jun 13 2016 14:48
I think there is definitely some benefits using them, but I would rather see them in the model to decide what to do with the proposals, but I have not spent too much time thinking about it.
devin ivy
@devinivy
Jun 13 2016 14:49
i'm just imagining the model receiving a proposal and trying to figure-out what to do with it. the proposal having a type and well-defined parameters sounds nice to me.
Jean-Jacques Dubray
@jdubray
Jun 13 2016 14:49
Yes, but I would prefer a one-to-many relationship between that type and the actions, in other words several action types can present a common proposal type.
devin ivy
@devinivy
Jun 13 2016 14:50
that seems fine!
it's just the proposal
Jean-Jacques Dubray
@jdubray
Jun 13 2016 14:50
I really don't like the plurality of actions known to the reducer, again makes no sense to me. Actions are one dime a dozen.
The proposal matches to the "unit of work" controlling the mutation of the application state.
Several action types can trigger the same unit of work
devin ivy
@devinivy
Jun 13 2016 14:53
certainly! the "unit of work" is what i'm calling the proposal–
the things that actions produce
i'm just imagining a simple protocol between the actions and the model.
i think it's one thing that throws folks off when looking at the SAM examples
Jean-Jacques Dubray
@jdubray
Jun 13 2016 15:14
Don't forget the Step semantics: proposals/mutation/learnings make up a step, you cannot logically process another proposal (though optimizations are possible) until the step completes.
SAM/PAL is aligned with Paxos, it means that the model mutation can be driven by a consensus protocol, I don't think any other programming models can do that.
Edward Mulraney
@edmulraney
Jun 13 2016 15:53
what does a proposal look like?
{ name: INCREMENT_COUNTER, mutation: state.counter = state.counter + 1 } ?
devin ivy
@devinivy
Jun 13 2016 17:33
@edmulraney there's no standardization around this. in the SAM counter example the proposal is just { increaseBy: 1 }
devin ivy
@devinivy
Jun 13 2016 17:57
my impression is that the proposal usually wont contain the actual mutation (as an anonymous function), since that makes the proposal specific to the model's implementation and obscures the parameters of the mutation, which might be important to the model in order to know whether to accept it.
for example, if i were incrementing a counter that's not allowed to go over 10, the model would be interested to know by how much you're hoping to increment the counter.
Jean-Jacques Dubray
@jdubray
Jun 13 2016 18:05
@edmulraney @devinivy The difference is that the mutation is expressed in terms of the model property values. It is unlikely that the UI would be in the position (other than the most trivial cases) to propose the correct values to the model. In any case, that would be a strong coupling between the view and the model.

my impression is that the proposal usually wont contain the actual mutation

au contraire, it's best to propose the actual mutation, as a unit of work, especially after enrichment (e.g. address -> postal address)

if i were incrementing a counter that's not allowed to go over 10

that's the kind of rule that would be implemented by the model (unless it is application specific). In general the model checks the integrity of the proposal in the context of the model. In SAM actions cannot "getState()"

devin ivy
@devinivy
Jun 13 2016 18:10
i was referencing the example above, where the proposal appeared to be an arrow function
in that case, the model would have a hard time understanding the mutation without trying it out
by "actual mutation" i meant "the function that performs the mutation"
Jean-Jacques Dubray
@jdubray
Jun 13 2016 18:11
@edmulraney @devinivy Interestingly "additions" (unlike change of address) are best represented by actions
{ increaseBy: 1 }
otherwise you can be facing some race condition
@devinivy yes exactly, you cannot always specify "the" proposed value (collections are another example, the proposal would be {addRecord:{x,yz}} rather than proposing the entire collection.
I know that's a bit unsatisfying, but I don't see an alternative when race conditions are possible.
Edward Mulraney
@edmulraney
Jun 13 2016 20:25
@jdubray in redux/react you dont need getState. There's stateless react / thisless react
luckily its not needed. you can make components plain javascript functions
Edward Mulraney
@edmulraney
Jun 13 2016 20:39
@jdubray "The difference is that the mutation is expressed in terms of the model property values"
model property values == redux reducer
i think people may be already using SAM in redux without knowing
weepy
@weepy
Jun 13 2016 21:57
@edmulraney how do u use PAL/SAM in redux without knowing