jdubray/sam

JohnGurin

@JohnGurin

Good day, everyone. I cannot find the "old" rocket launcher example where I thought I would find an answer. Here is the question:
when a timer is counting we have to re-render the timer in a view, where should nap go in the example?

state.render = function(model) {
    state.representation(model)
    state.nextAction(model) ;
}

In the example above render is inside state.representation(model) and if place nap check there to, then
nap and nextAction could run "simultaneously".

Is this valid approach:

    const sr = stateRepresentation( model )
    if ( nap( sr ) ) return
    render( sr )
    nextAction( model )

So if nap is true, there is no render, if nextAction is needed, then it is done only after render

https://github.com/jdubray/sam-samples/blob/master/inferno-rocket/index.html#L251-L255

Pete Barnett

@petebarnett

Hi all - I'm wondering about a situation where multiple actors implement "Next Action Predicates" that would run given the current state... If an action starts a new cycle of the reactive loop, is it simply the case that the 2nd one can wait for that to happen until it's invoked?

Is there a scenario where that might not be suitable? like a state change consists of "a product was added to the cart", and there are 2 NAPs that want to respond to that specifically... by the time the second one is invoked again, that is no longer the latest action

it makes me think there is a class of responsive action, that needs to be queued. and when it's re-invoked, decides for itself whether it still wants to act

Pete Barnett

@petebarnett

(I guess otherwise they could be composed, but only if they knew the nature of the other, and knew they were composable, and that seems more complicated than giving them a chance to re-evaluate after being popped from the stack)

then my mention of a stack raises a new question - should it be resolved that way (depth first vs breadth first)

Pete Barnett

@petebarnett

I think I've answered my own question by rubber ducking it... If you consider the model to be closed, these actors are effectively external- in that they care to be notified about changes... But the natural reaction would be to raise a new action, and we know that actions must be queued due to the synchronised nature of the model.
So the queing becomes front-loaded, instead of implemented at the nap

Pete Barnett

@petebarnett

Revisiting the above with more clarity-

Of couse a SAM "machine" only has 1 NAP function, but my project is an "cart engine" (ecommerce) that supports modular extension. Modules have an interest in implementing their own NAPs against the cart state.
The top level NAP therefore delegates responsibility to registered modules, invoking each of their NAP implementations. In effect these modules are collaborating without knowing anything about each other, but you can't just compose their actions.

This would be no problem if they only need to respond to the current state- It is only when they start to care about the "event" that led to the state change, that things become problematic. The event can be captured by the SAM machine and rendered into the current state. e.g. "itemAdded".
Child NAPs can respond to that, but of course a new cycle begins with each action, meaning the next time round, it would not be "itemAdded" anymore, and the 2nd NAP missed its chance to act.
Rocket launcher is simple because when countdown gets to 0, you stop. It's a terminating condition. But think about counting upwards, and needing something to trigger only after, when "count > 20". You need to synthesise an event like "count exceeded 20", otherwise it'll trigger in an infinite loop.

So going back to my problem - to solve the "multiple proposed actions", actions can only be queued. But from my own reading (not sure if SAM or Lamport papers) it seems like a fundamental principle that intents are strongly associated with the state from which they are raised, to the point where it seems legitimate to require a "version/sequence number" on an intent, and to reject it if the model version has changed since then.

If I start queing actions however, I break that principle... actions become deferred to be applied against future unknown states and that doesn't feel right! But I did come up with a pattern which I think addresses the problem in my use case, and would be interested to hear thoughts.

I change the wiring so that a NAP returns model proposal(s) AND a "defferedApplication" callback.
The idea is that you can define a secondary predicate, evaluated against the new state when the action is about to be applied - to determine whether it is still valid or not. i.e. return true or false.

If the change (a.k.a. Event) that caused a NAP to propose an action was "Item added to shopping cart", the "deferredApplicatoin" callback would potentially evaluate that the product was still present in the cart.

Pete Barnett

@petebarnett

...and if the above sounds like it's bending the rules with magical machinery, I would argue that it's possible to implement as a pure SAM model, by providing an action called "setFutureActions". It accepts a list of action identifiers, and of course those can be output in state representation.
You then have one pure NAP (a single function) that happens to call out to its subscribers with the current State Representation, and collects a list of "future actions". It then looks at the current state representation for existing "futureActions", and returns a proposal equivalent to "setFutureActions" + "the action that was at the front of the queue".
In this way, you get a synchronised model with a single NAP and the queuing built into the model itself.

Pete Barnett

@petebarnett

(this is all probably equivalent to NAPs just returning callbacks which produce proposals at the time they're called)

Daniel Neveux

@dagatsoin

I ran into this problem to. I solved this by adding a new responsibility to the StateRepresentation function : define what actions could.be triggered at a specific ControlState.

It is barely equivalent of what exists on the Safe demo that JJ wrote a few years ago.

Daniel Neveux

@dagatsoin

Regarding the intent queue, you can have conflict when two actions in the queue are allowed in the same ControlState but those control states can be separated in time (e.g.: the cart can be empty, the filled, then empty...). In this case I solved the issue by tagging intent whith exact same mechanism than, one more time, the SAM Safe exemple.

Another situation is also on a project I am working on, a lag compensation engine for multiplayer game. In this case I have to deals with multiple users with different ping. And this is solved by using a Lemport Clock which fits perfectly with SAM, as the exemple above, due to the "timed" nature of the algorithm.

Daniel Neveux

@dagatsoin

(writing from my phone, sorry for typos)

Pete Barnett

@petebarnett

So in the end I implemented “multiple NAPs” as callbacks- each “module” taking part in the flow has a chance to return a callback during the nap phase instead of presenting. Callbacks are added to the stack and the loop completes when that stack is empty. Each callback may receive a different state represention but it is up to the implementation whether it wants to act.

The first callback in the stack would be executed immediately anyway. Only where more than 1 is registered would each potentially receive a new state. This again only happens when a listener cares about events rather than state

To clarify, these callbacks are not registered upfront - they are returned in each cycle, where something wants to act. They are essentially single event consumers, or promises

Pete Barnett

@petebarnett

If something is dependent on a particular control state. It can determine when the callback is invoked that the control state is or isnt present- and do nothing

So yeah, i think i realised what you were sayinhg about conflict with intent queue- which is why this is still an extension of the nap, which is simply deferred- these receive the current state when they are called and present proposals (still inside nap)

Daniel Neveux

@dagatsoin

Is there a name for a pattern that can be used and composed at all level? Business level, view level, infrastructure level, etc.

Jean-Jacques Dubray

@jdubray

@JohnGurin you are correct, thats why nextAction later became the next action predicate such that you could control the rendering of the view (or response to a client) based on the next action being triggered. Some next actions allow for rendering others don't. Its not because one action gets triggered that it would prevent rendering, it's on a case by case basis. (Sorry for the delay)

Jean-Jacques Dubray

@jdubray

@petebarnett @dagatsoin SAM is not prescriptive on what happens in nap, the are a lot if actions that can be executed in parallel (if an action's role is to present a proposal)

That's why its not a good idea to implement actions that manipulate the state like MVC, or general event handlers.

You have to distinguish of course between the case of two SAM instances interacting with eath other (not a next-action in SAM sense, its a re-action).

Jean-Jacques Dubray

@jdubray

A true next action, is rather a trans-action. An action has happened (debit account), a next action must now take place. For payments, you need both the credit action and a timer, to recredit the account on timeout (no confirmation).

The is really no logical barrier on how many next action you can initiate. By definition an action has to operate on a stale state, that's why creating proposal rather than orchestration state changes is the paradigm shift that SAM introduces.

Pete Barnett

@petebarnett

Thanks @jdubray - that is enlightening

Jean-Jacques Dubray

@jdubray

The changes are subtle when you shift from orchestrating state changes to submitting a proposal, but the code is much easier to reason about when multiple actors (actions) can be involved, because very quickly the orchestration code needs to become stateful, it's hard to perceive that transition and let alone implement it, orchestration code is inherently hard to write (say WS-BPEL if you ever took a look at it or AWS step functions). People will argue: "...but you can use function generators in javascript", sure but the state is trapped in the function generator, not really accessible to any part of the application (and then what happens in the case where the process crashes and the function generator state is lost). SAM works in all cases, re-action, trans-action, simple action, ...

Jean-Jacques Dubray

@jdubray

SAM is also inherently easy to persist (see the SAM-SAFE implementation)

david kaye

@dfkaye_twitter

@jdubray For clarification, by "function generators in javascript" do you mean generator functions that create iterable/iterator objects?

Jean-Jacques Dubray

@jdubray

yes, sorry: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/function*

That's a problem that Redux was never able to solve, unfortunately.

david kaye

@dfkaye_twitter

Have you seen this? https://www.freecodecamp.org/news/async-generators-as-an-alternative-to-state-management/

Jean-Jacques Dubray

@jdubray

No, I had not. Generator functions could be used to implement SAM (as you can see, it's easy to "wait for an action"), I am not sure about the other parts of the pattern like render and nap. A generator function inherently yields to the caller and wait for another call (which work well for even handlers and request/response types of interactions). I am not sure about a "reactive loop implementation" where you pass messages along the control thread.

Jean-Jacques Dubray

@jdubray

After that the author gets into the mode "with my new hammer, everything looks like a nail", that piece of code is horrendous https://jsfiddle.net/awto/y3x6L9wu/

Slađan Ristić

@sladiri

Generators seem to be another way to implement state machines in plain javascript. Another example https://codepen.io/rgdelato/pen/vGNRqP. I wanted to try that to represent the control state, in some cases it might be useful, when your logic benefits from being defined as a state machine.

Slađan Ristić

@sladiri

But yes, the generator state is ephermal, but maybe you can still benefit because it is easier to read. Being able to serialise the state is really nice, that is what we do to save state in a SPA when navigating away from a page and want to come back. We got this feature almost for free. (Heh, so maybe generators are not really possible to use easily.)

Slađan Ristić

@sladiri

messages can only be bits, not commands

just saw this and it reminded me of the "proposal pattern". This seems to me the most foreign principle when explaining SAM, but it has been proposed before, no pun intended
https://www.youtube.com/watch?v=9MqVfzxAp6A

Slađan Ristić

@sladiri

on my millionth thought though, this is just decoupling systems via events :)

Jean-Jacques Dubray

@metapgmr_twitter

I may I have shared this article before (from Achim Schneider): https://codingconnects.com/sam-pattern

1 reply

https://medium.com/codex/user-interfacing-software-design-patterns-revisited-2ac1dcfd445d

1 reply

david kaye

@dfkaye_twitter

Andrew Ray updated his blog design and tweeted about it so I revisited and found this Flux pattern post (dated Nov. 13 2021, but I recall seeing it circa 2014). Have to say, understanding the SAM pattern helped me understand Flux (without Redux) this time around.

https://andrewray.me/blog/the-mental-model-that-helped-me-finally-understand-flux

Also a list from a different tweeter about 3 state management libraries:

Zustand is for flux-like state, like Redux.
Jotai is for atomic state, like Recoil.
Valtio is for proxy state, like MobX.

Original tweet at https://twitter.com/ralex1993/status/1457782056075730950

Jean-Jacques Dubray

@metapgmr_twitter

@sladiri this is coming really the definition of Actions from Dr Lamport that i tried to translate, and i dont claim that any ideas in SAM are mine, I am just a translator and if anyone has a better translation, I'll take it. I just don't believe that scientists the caliber of Newton or Lamport are blogging all day (like me), so i tend to be dismissive when people who thought about something for 10 min come up with better alternatives to TLA+ for instance.

Jean-Jacques Dubray

@metapgmr_twitter

Who needs a new framework? https://remix.run/docs/en/v1/tutorials/blog
it doesn't seem to have state management built in (who needs that anyways?) https://remix.run/docs/en/v1/guides/data-writes#remix-mutation-start-to-finish

Jean-Jacques Dubray

@metapgmr_twitter

That's unrelated to SAM, but this project is near and dear to my heart, we have been busy in my engineering organization building a schema architecture that I designed 12 years ago. GraphQL has been a game changer to realize that design. I expect that this now FOSS project will solve a major pain point in microservices: https://github.com/nav-inc/nav-schema-architecture

Special credit to Michal Scienski, Daniel Zemichael, Jeff Warner, Jovon McCloud and Brent Tubbs. Michal has created a build pipeline that's out of this world. I expect that it will take a life of its own and make a durable impact on low code projects.

Where communities thrive

People

Repo info

Activity