These are chat archives for jdubray/sam
@nerdo You are correct, transient state should be avoided. But in the case of a spinner you are limited when the view is functional. HTML does not have a good way of dealing that case. SAM's actions are thunks, and that's a bit my issue with React, I believe they tend to direct the developers with a subpar programming model (where a Redux action is by default an event). Redux's default programming model tend to clump together proposal, mutation and state representation in the reducer, which I believe is the wrong thing to do. I don't believe anyone should use Sagas since they fragment the state tree.
It could be considered part of the control state, but then I ask myself if I serialize the state, would I want to include or exclude it, and it's clear to me that it's transient.
Exactly, that's the kind of question that we need to ask, that's why in the sample I pointed out, I don't use a transient control state, I just assume that when a proposal comes, the spinner is no longer needed, but that obviously will not cover more complex cases where different proposals might come before the data is fetched (different widgets working concurrently).
Am I off base
no, not at all. You should also consider a component model where this control state can be easier to reason about. I don't want to give the impression that control state management is a lot easier with SAM, all I have been arguing is that SAM helps you manage control state more easily in a functional HTML architecture. In other words, you don't have to transform you entire programming model into a FSM (which would be a disaster). SAM let's you weave control state management as needed, but I can't argue that it makes it simpler, if that makes sense.