These are chat archives for jdubray/sam

28th
Aug 2016
Mike Nichols
@mnichols
Aug 28 2016 20:03

Hi @jdubray ...I am driving out a react-native application using their NavigationExperimental using SAM. One thing I am wresting is the factoring of code implementing a 'navigator' history component for handling screen transitions, etc. I get that the 'State' portion should be a computation of current application state making it itself essentially 'stateless'. But a history/navigator component inherently requires being stateful...like keeping track where the user is inside a navigator sequence.
My gut tells me this:

  1. PUSH/FORWARD: issue new 'actions' when doing moving forward ('push' in navigator terms). This would go through the entire SAM loop and State would potentially push another screen in response
  2. POP/BACKWARD make model state serializable so that I can store snapshots of the model to support going 'back' ('pop' in navigator)...this pop command would not go through the SAM loop but would simply pluck off the historical snapshot and use that to inject in the navigator for 'back' actions.

Does this seem like the right direction to go?

Jean-Jacques Dubray
@jdubray
Aug 28 2016 20:12
@mnichols It probably depends. What you describe sounds more like undo/redo, which yes, should be done via snapshots, that's one of the main advantages of using a single state tree.
That being said, I can think of edge cases where other events are interleaved with "history" and manipulating entire snapshots will not work well.
I know that the trend in Angular and React is to have a "library" for everything. I personally don't like that approach. As you know, I believe it's eventually faster and cheaper to build what you need. These libraries should be viewed as a starting point, not as a blackbox.
Mike Nichols
@mnichols
Aug 28 2016 20:22
Thanks @jdubray for the input!... taking on cross-device transition dev is outside my scope on this project so I'd rather be a consumer there. The matter of knowing how to transition from one control state to another without having a stateful object tracking that has been a sticking point to other devs on my team. If view-related concerns don't belong in application model state it's non-obvious how one intelligently makes transition decisions.
Jean-Jacques Dubray
@jdubray
Aug 28 2016 20:33
That's a very legitimate concern!! The SAFE library (sorry I complain about library and I recommend using one) explains one approach to solve that problem. Again, you should view it as a starting point, not as an end-all be-all library. I wrote this library to show how to validate actions/transitions from the knowledge of the current control state and indeed you need to keep track of some "state", however, I would argue that it is of different nature from the application state, since it can always be (re)computed from the application state, so it is more an optimization than a "stateful" mechanism.
SAFe stands for "State-Action Fabric"
Mike Nichols
@mnichols
Aug 28 2016 21:12
cool @jdubray i'll study that today. i remember seeing it before but forgot. i appreciate your remarks on 'different kind of state'. i have explained that to the team before too..for example, view libs like react and so on have to hold on to some form of state to do the voodoo that they do so well.
Jean-Jacques Dubray
@jdubray
Aug 28 2016 22:47
Yes, I believe there is no way to escape that, it's not a good idea to put everything in the model. I would argue that everything that is required to derive the "control" state in the State function should be in the model. Things like Sagas in Redux are an anti-pattern.
That's probably the most important lesson to remember from SAM. It's not about side effects it's about control state. Side effects appear prominent because they make it visible when you are applying actions in the wrong control control state. I understand that sometime it's not always optimal to follow that structure, but it is always safe!!