These are chat archives for jdubray/sam

May 2016
Fred Daoud
May 07 2016 11:34
@jdubray I am guessing this is quickpaster:
Jean-Jacques Dubray
May 07 2016 11:38
Yes, I just had trouble (and enough time) to grasp what it was about
Jean-Jacques Dubray
May 07 2016 11:48
If people are interested to continue the discussion on RFP, the fundamental problem is "consistency". When you look at Cycle or Redux, their view of consistency is "functional", I direct all events to a pure function, which when it completes makes all the changes visible at once.
There are two fundamental issues with that:
  • the order in which the actions are issued is important
  • the function (reducer) may not be able to encapsulate all the changes that are relevant to achieving a stable state
In particular processing an action requires starting from a stable state
Jean-Jacques Dubray
May 07 2016 11:56
So the question that people need to answer is when is it safe to process an(other) action? I would argue that it is that question that Cycle and React cannot answer properly
SAM does not try to answer that question, in a way it pushes the burden on the developer, because in reality it depends, but at the same time, it provides enough structure to implement one of many different strategies to achieve the desired outcome (e.g. action hang back)
Jean-Jacques Dubray
May 07 2016 12:01
I would argue at this point that Cycle and Redux will not be able to sort out all the issues that will arise from Order/Visibility, because the number of combinations is just too high. Redux has already started to give up and tell people, just write a Saga, cycle has not reach that point and they are still looking for the "pure" route which they will never find
Sagas work in the same sense that given enough resources you can make anything work in JavaScript, but the problem will be that you will have to write Sagas to deal with each individual events. That will not scale well for large applications. Imagine having to write and debug dozens of Sagas just to deal with action ordering, cancellation,...
Jean-Jacques Dubray
May 07 2016 13:58
Here is a great example where you would need model knowledge to make a query, which tend to drive to the conclusion that there is not one place to call "APIs".
It would not be wise to have the actions have the knowledge as to whether WiFi is on or not.
Personally, I would encapsulate all the CRUD (including Read) in the model. That would be the best way to ensure that the application works seamlessly online or offline.
devin ivy
May 07 2016 16:32
so an API call occurs as a reaction to a proposal?
Jean-Jacques Dubray
May 07 2016 17:29
Again, as I said before, logically you should trigger an action in nap() and the action you trigger would depend on whether you "connected" or not, but you would have not reached a state valuable enough to render until that action completes. Of course the drawback is that now that kind "action" embedded in the acceptor cannot be cancelled. Probably needs a bit more thinking.