These are chat archives for jdubray/sam

4th
Nov 2018
karlhp
@karlhp
Nov 04 2018 01:37

Hi @jdubray, hope you are well! I am trying the get my head around the SAM pattern once again, hence a few questions.

a.) Does the SAM pattern promises less boilerplate code than Redux? I guess not, right?

b.) I wonder why the function present(proposal) isn't simply called propose(proposal). Is it because of "present state" with a "proposal for new state"?

c.) What is a simple as possible real world use case scenario where I can demonstrate to myself the advantage of the SAM pattern, a use case which would be difficult to achieve or take more effort with Redux or MobX. There are many examples which show the pattern but IMO don't cleary show the advantage over the other patterns. Would that be a use case with some possible race conditions (for example between a user interaction and server response) or something that requires to handle multiple actions before updating the model, state and view?

Could it eventually be a use case like the flux challenge?
https://github.com/staltz/flux-challenge

I could try the flux challenge with the SAM pattern and lit-html unless you have a better idea.

Thanks,
Karl

karlhp
@karlhp
Nov 04 2018 03:26
@jdubray, one more question.
d.) Why would you use the SAM pattern together with Redux or MobX?
karlhp
@karlhp
Nov 04 2018 13:29
@jdubray, I think I understand the SAM pattern now, yet I need to code something. I'll think of some use cases but input is very welcome. I am still wondering why someone would use the SAM pattern with Redux or MobX. MobX may make sense but Redux?
Jean-Jacques Dubray
@jdubray
Nov 04 2018 17:19
@foxdonut the problem with React's programming model is that it believes that most of the state is tied to components, as opposed to the application state. Redux tried to pull in the other direction, but somehow failed along the way (I believe because of its functional structure), I don't dispute that some state could be strictly tied to a component (for instance, a date selector, no other part of the application need to know whether the date dropdown is displayed or not) but in general that is not true and you are doing a big disservice to yourself by wrapping application state inside a component. I though it was clear enough to the React community by now, but useState and useEffects are anchoring state management in the component. I am not why that is.
Yes, I agree with your approach, that's the beauty of proposals and the ability to accept or reject them, this kind of logic becomes trivial to implement. I believe I had done something similar in the spinner example in the SAM repo.
Fred Daoud
@foxdonut
Nov 04 2018 17:21
@jdubray :thumbsup: thanks!
Jean-Jacques Dubray
@jdubray
Nov 04 2018 17:30
@leosbotelho I don't have any experience with the actor model, from what I understand it's probably harder to implement SAM with it because of the absence of global state, but I guess you could manage a session rather effectively where the response of an actor is passed to the parent actor's model as a proposal. Again, not a specialist.
@foxdonut sorry I meant to look at your new SAM implementation. There is a lot of work behind it and I have not been able to free up the time to give it justive. The last few months have been very challenging.
Jean-Jacques Dubray
@jdubray
Nov 04 2018 17:36
@karlhp
a) I would say slightly less but not significantly less. The problem with Redux is that if you implement the default structure (actions as data structure, immutable reducer and no state representation) you would probably make it a lot harder than it should be. The default structure in SAM is actions as pure functions (with respect to the model), a mutable model and a separate state representation. I believe your code should be easier to write to any alternative, including component base state management. We can only compare at scale, small applications/samples would not show much difference. Unfortunately, Last year I wrote a couple "real-world" solutions with SAM with straight ES6 and Angular and I felt that complexity was increasing linearly, I never felt SAM was a burden or much boiler plate.
b) not being a native english speaker I may not always pick the most natural world. It seems to me that presenting a proposal sounds better than proposing one. It also conveys the idea that the action has no control over the outcome.
Jean-Jacques Dubray
@jdubray
Nov 04 2018 17:42
c) the best example I can think of is writing some code that retries an API call in case it fails. Of course with BlueBird that's one line of code (you can't beat that). You should then write it with promises (you'll need some recursion), and compare the clarity and maintainability of the code. For instance if you want to support more complex scenario where the retry period increases with the number of retry or would depend on an external factor (e.g. the user chaning his/her mind and having to cancel the retry). SAM has always given me those ahah moment, that was a big one this year for me. All this in under 20 lines of code and no library.
The flux challenge + lit-html sounds good, but the API retry should really clarify how easy it is to reason about state. SAM's complexity remains constant over time (as long as you adopt a light weight component model to organize actions, acceptors and reactors).
Jean-Jacques Dubray
@jdubray
Nov 04 2018 17:52
d) SAM provides a way to reason about Redux, I would argue that since it is based on TLA+ it is SAM -> Redux rather than the other way around. I came up with SAM in June 2015, after talking to Dr. Lamport from Jan to June. I was originally using it to implement complex API orchestrations (a la BPEL). I would say that knowing about SAM would make it easier to use Redux.
I talk to Michel originally before he came up with his own way to manage state. I had good hope that he would feel there was a good match between Mobx and SAM, but he ended up using an OOP programming model where action directly manipulate the state. Again, in programming everything is possible, SAM being just a pattern you can use it anywhere, including in MobX-state-tree. My approach has always been to get people to talk and reason about the structure of their code but it seems that this discussion is nearly impossible to have. Incidentally I hate FP now that I been forced to use it for the past few months. FP, like OOP, like SAM is a pattern that can be applied and offer some genuine solution in a given context, but as the structure of any application, it simply makes no sense at all, not just from a resource or maintability perspective but from a pure programming model perspective.
karlhp
@karlhp
Nov 04 2018 18:28
@jdubray :thumbsup: thanks four your detailed reply and sharing your knowledge. There is a lot of outstanding material to read here, superb channel. I finally understood the value of the SAM pattern and I am anxious to apply it to a use case you described.
Daniel Neveux
@dagatsoin
Nov 04 2018 18:37
I would just add my 20cts as the fact that the model im/mutabilty is up to you. At the end the important point is that the State function must be aware of the new model state.
Daniel Neveux
@dagatsoin
Nov 04 2018 18:42
Also, a recurring point poping up in this gitter and which you will certainly meet during your implementation is that the State will need to know what changed in the model.
On my project I accomplished this by sending all the proposals accepted by the model to the State function.
I think to use Immer to help on this on my next refactor.
Jean-Jacques Dubray
@jdubray
Nov 04 2018 19:28
@karlhp Another example you could try is to fix the bug in example 2 (Stateful Component). It shows an inherent problem of managing state in components.
@dagatsoin yes, this is true, but it seems to me that immutability is uncessary. Yes the deltas are important specially in the context of cleaning up (such as a component is no longer displayed). Another approach I use is to create anscillary states that can then be used to decide on the next action.
Jean-Jacques Dubray
@jdubray
Nov 04 2018 20:20