These are chat archives for jdubray/sam
componentDidMount). so currently i've been putting this in NAP, where
if !state.isReady -> hydrateAction()
hydratebut this may not be the best idea
state.readyfunction will be false, and the view will render a
loadingscreen. in our NAP we dispatch the action
getUser(...)and then on the second render we can display the user
@mnichols so I am trying to avoid
modeling states explicitly
It is sometimes clearer, it is sometimes a burden. SAM / TLA+ offer enough structure in which a state machine can be landed, but does not require that you think in terms of State/Action/Transition
@jeffbski I struggled to understand that state function also, and I think that's because I couldn't work out what it's responsibility was. Rendering the view? Executing the next action? Where is the
state? etc. I realised it's none of these, and that it's closest familiar term is really "status" or control-state. Then I differentiated what the state function can help determine, vs what the state function actually does. How I understand it is: the state function only calculates what the current control-state is of the component. From this control-state you can then:
But there is no reason why the
nap function must be called inside the state function, and personally I don't do this because I believe it's:
I think the state function's only responsibility is to determine control-state. You can put
nap in the state function but I don't see a benefit in doing so. I think it's the responsibility of the assembler to call
nap, not the control-state function.
I think it's the responsibility of the assembler to call render and nap, not the control-state function.
I am not opposed to it, for me it was the dependency on the control state that "coupled" those two activities, but either way it's ok.
State machines provide a framework for much of computer science. They
can be described and manipulated with ordinary, everyday mathematics—
that is, with sets, functions, and simple logic.
for much of computer science
hydratefunction is required. The reason being is, one of the strengths of SAM is removing BL from the view. So it shouldn't matter whether we use HTML templates, React, Angular, or console.log. The logic shouldn't depend on the rendered component to dispatch an initial action, in the same way we don't depend on the view to dispatch post-render actions (nap).
A specication is a written description of what a system is supposed to do (p1)
Our basic tool for writing specications is mathematics
TLA+ specifies a system by describing its allowed behaviors|what it may do in the
course of an execution.
TLA makes it practical to describe a system by a single formula
V = S( vm(M.present(A(data))), nap(Model) )since I think it helps to describe what is going on in one shot. I'm not sure why there is an S and a vm. I was kind of thinking the S represents the State function, but then I thought vm was for view-model so I'm confused a bit since I didn't know we'd have both. Also while the function is useful for helping understand, is it accurate? The
presentcall is asynchronous (reactive) it doesn't return anything. Math and compatibility of functions is straight forward when synchronous. Maybe TLA+ has some nice ways to represent that and I must guess that you were able to write it in TLA+ form, but I'm guessing it might be a bit involved from reading the examples in the book.