These are chat archives for jdubray/sam

5th
May 2016
Jean-Jacques Dubray
@jdubray
May 05 2016 08:57
Looking at that pretty picture of Redux, it begs four questions? https://twitter.com/thekitze/status/727821044308967425
1/ Where are the sagas?
2/ since the reducer is encapsulated in the (impure) store what is the point of making the reducer pure?
3/ what is "state" in that picture, never heard of something called "state" in Redux.
4/ Up until today, Action Creators were optional in Redux, it looks like Redux is on its way to abandon its principle #2 (action as events)
Jean-Jacques Dubray
@jdubray
May 05 2016 09:05
On the same note, someone created the cycle.js representation https://twitter.com/CezaryDNowak/status/727839955356164096
Stardrive ENGG
@HighOnDrive
May 05 2016 15:42
Both Redux and CycleJS are architectures that leave much to be desired. Redux is the result of building blindly and just piling it on, while CycleJS just says here is the one size that fits all, we don't care about the real world, take it or leave it.
Jean-Jacques Dubray
@jdubray
May 05 2016 16:11
I found this presentation about zone.js this morning and when you watch you get this sense for Google (and Facebook) engineers, GUIs are just chaotic systems where anything can happen at any time. https://www.youtube.com/watch?v=3IqtmUscE_U
devin ivy
@devinivy
May 05 2016 17:35
@jdubray seems like the redux folk are concerned that (at least with SAFE) pending actions block subsequent actions. you're just saying that presentations to the model are controlled, right?
Jean-Jacques Dubray
@jdubray
May 05 2016 17:37
yes, that's all I am saying, it's non blocking for the user. You need order, you can't have an ad hoc strategy for every event the UI emit.
Not quite sure what they don't understand. Just try to write a Saga for dealing with this kind of issue, you are dead.
it's actually not "pending action", you can trigger actions that will take a while to present their data to the model, because you are not ready to mutate the application state until the action's event has been enriched with some back-end data. That's a hard problem to solve. Without something like TLA+ and SAFE you have to write bespoke code for every type of event that can be potentially cancelled.
Jean-Jacques Dubray
@jdubray
May 05 2016 17:44
SAM / SAFE allows you to build a "step" based strategy to cancellation / presentation. As I mentioned in the discussion in the list, you can even continue accept results from actions triggered in a previous step, as long as your state machine allows for it. I can easily implement a strategy where an action overrides the safe identifier with a wildcard. As long as the action type is "acceptable" (allowed), it does not matter which step it was initiated. These kinds of semantics is very powerful.
devin ivy
@devinivy
May 05 2016 17:48
:thumbsup: makes sense to me. remember flux's waitFor()? reflux has interesting semantics, though, and i think remains ahead of the game in some ways– actions can be joined in multiple ways! see https://github.com/reflux/refluxjs#joining-parallel-listeners-with-composed-listenables
Jean-Jacques Dubray
@jdubray
May 05 2016 17:50
My concern with "action orchestration" is that this can only work when the results of the actions is presented to the application state/model as a unit. If the orchestration's intermediary state is coupled to the application state then you are in trouble. There is just no way action Action -> Model -> State (next action)
As soon as you break the paradigm you expose yourself to bugs and hard to maintain code
devin ivy
@devinivy
May 05 2016 17:51
hm, i need to think about how this relates to reflux.
you mean if i have a special action that is the join of two other actions, when one of those has fired but not the other, then i'm stuck in a hard-to-describe intermediary state.
Jean-Jacques Dubray
@jdubray
May 05 2016 17:53
It looks like Reflux has a "tick" (step) too:
// node.js env
Reflux.nextTick(process.nextTick);
devin ivy
@devinivy
May 05 2016 17:54
well, yes, but it's a little weird. actions can be sent-off on a tick or synchronously.
Jean-Jacques Dubray
@jdubray
May 05 2016 17:54

special action that is the join of two other actions, when one of those has fired but not the other, then i'm stuck in a hard-to-describe intermediary state.

The key is not to confound API call with action. An action can encapsulate multiple API calls, no problem, as long as the intermediary results / state of the orchestration have to bearing on the application state until the entire result set if presented to the model

devin ivy
@devinivy
May 05 2016 17:55
i understand that in the case of SAM, but action means something different in *ux-land.
Jean-Jacques Dubray
@jdubray
May 05 2016 17:55
It's all about mutation, you cannot tamper with mutation, an action presents data to mutate the application state.
I know, that's why it would be helpful to converge towards similar semantics
devin ivy
@devinivy
May 05 2016 17:56
you could call actions "proposal-creators"
and it would start hinting at the relation to actions/action-creators.
really your actions are much more like *ux's action-creators.
Jean-Jacques Dubray
@jdubray
May 05 2016 17:56
I have proposed event/intent/action where:
  • event = press submit
  • intent = submit change of address form
  • action = the function that translates the intent into a dataset that can be accepted by the application state/model (including invoking the API getPostalAddress())

really your actions are much more like *ux's action-creators.

Yes, agreed.

devin ivy
@devinivy
May 05 2016 17:57
btw it's interesting that the animated diagram of redux you posted earlier clearly sent a thunk!
Jean-Jacques Dubray
@jdubray
May 05 2016 17:57
Interestingly the Redux camp did not answer my question where they put the persistence API calls...
yes but the diagram does not represent persistence at all...
Have to go to a meeting
devin ivy
@devinivy
May 05 2016 18:02
enjoy :) me too!
Fred Daoud
@foxdonut
May 05 2016 20:19
@jdubray do persistence API calls in SAM belong in actions (e.g. make AJAX request, receive response, present to the model), or in the model itself (present data to the model, model makes AJAX request and updates itself with the response)?
brusand
@brusand
May 05 2016 20:23
I prefer un action then you can display an ui for waiting thé request if un model you can t. I do all api backends un actions
Jean-Jacques Dubray
@jdubray
May 05 2016 20:23
IMHO, they belong to the model because they could influence the outcome of the acceptance stage. Logically, they would be an action invoked by the next-action predicate
I think both models are ok, If you make them an action, I believe that it can be more complex to deal with exceptions (specially when you need to display them and the rendering has already started). If all goes well, these actions would simply present the same data from the model, except for primary keys on create operations which will be coming back from the store and injected in the model.
brusand
@brusand
May 05 2016 20:26
my states are a mixed of qui.value ans API.value . So when i have a ui.value and not the api one, i fetch it in action.
Jean-Jacques Dubray
@jdubray
May 05 2016 20:27
yes, clearly the read/query belong to the actions, they would present the result of the query to the model
I thought you were asking about the updates