jdubray/sam-architecture

Daniel Neveux

@dagatsoin

for now I code in quick and dirty, but I will maybe have a bunch of hours this week to minimize my SAM implementation. And maybe have a POC of this future NAP action composition.

is this basically nap() implemented component-wise using inversion of control?

I am not sure what you mean.

devin ivy

@devinivy

i didn't mean component– i meant service

sorry, that was poorly written. lol.

i really mean, there will be some way for services to "register" with nap().

and nap() will use some common API of each service to learn what actions they want to fire.

Daniel Neveux

@dagatsoin

ha lot more clear :p

yes it is that

devin ivy

@devinivy

sorry about that– way lazy of me. so, what would the common service API possibly look like?

Daniel Neveux

@dagatsoin

Very simple just a reactTo(model):ActionArgs

devin ivy

@devinivy

makes sense :thumbsup:

Daniel Neveux

@dagatsoin

and the Nap will loop over all the registered services to retrieve potential actions.

Jean-Jacques Dubray

@jdubray

yes, very elegant and simple.

Daniel Neveux

@dagatsoin

I am working on the refactoring of my SAM implementation. I am still a the naming step.
I still struggle on the word State.
As you wrote:

Unintuitively, the State does not hold any “state”,

It is unintuitive. And I concur :) So why call it like that ? I can get that it could be linked to the state machine control state, but as you wrote:

SAM does not require the State implementation to be based the semantics of a state machine

So what it the reasons behind this name?

Jean-Jacques Dubray

@jdubray

It's really about the difference between property values (Model) and State representation (which includes control state)

Daniel Neveux

@dagatsoin

So it means that the semantic should reflect what is created/updated by a reactive function.

Or if the semantic should reflect what is done by the reactive function, it could be "Learn".

In first case, this could make sense as you wanted to show the difference when we look in to the model and what the pattern makes with the model.

Daniel Neveux

@dagatsoin

State = what the pattern produce at the end of the reactive loop

State = representation of the enhanced model (the view or view model) + the next possibilities of enhancement (available actions)

Daniel Neveux

@dagatsoin

shit, now I love the term Learn...

Daniel Neveux

@dagatsoin

I will create an interface Learner implemented by a State object!! :beers:

Jean-Jacques Dubray

@jdubray

yes, PAL is a great way to describe the pattern

the state representation. is really about decoupling the view(s) from the model. I think that's essential
And yes, it's best implemented as a reactive function, unlike mutations

Janne Siera

@jannesiera

What does PAL stand for?

If the 'next action' is represented by the NAP, then how is 'State' of SAM any different than View in any other Pattern/Framework?

In your comparison between Redux+React and SAM you say:

View is a function of the state | State representation is a function of the model

So, is state representation not the same as view, and model the same as state?

Jean-Jacques Dubray

@jdubray

PAL = Propose/Accept/Learn, it's coming from the Paxos algorithm that was also invented by Dr. Lamport.

@jannesiera things are a bit fuzzy at the boundary between State Representation and View.

For instance in Angular or React, you pass "props" to the view. So the state representation is a series of props

When you use ES6 (template literals), the way I implement it is generating HTML in the state function, then I pass the "state representation" to a display function that mounts it in the UI

I probably could have chosen a slightly cleaner implementation where the state representation is always "props". I do however implement all the HTML generation in a "theme" such that I can interchange these themes when necessary.

Janne Siera

@jannesiera

I updated my 'Factoring event handlers' gist to try and incoorperate State Representation (I'm interpreting it as ViewModel). Could you take a look and tell me if I'm on the right track?

Line 306
https://gist.github.com/jannesiera/754f87ae879d9216a78aceb85a8d7010

Jean-Jacques Dubray

@jdubray

Yes, that's close. In general I prefer to decouple the view from the actions (the event listeners would dispatch to an action) but that's not so important. Otherwise, yes, that's a standard SAM loop.

Janne Siera

@jannesiera

@jdubray Thanks. Nap is still missing, I'll look into that today :)

raduab

@raduab

@robwormald

at this point the burden of proof is on you, i think. I think your idea is quite interesting, but there are thousands of real world applications in the wild using redux/flux like patterns, and so far what i've seen of SAM is mostly theory.

The

raduab

@raduab

The problem is that the author of SAM has already explained very well his concept and also spent a lot of time replying to questions about it. There's no excuse from anyone in the field to not understanding this technology. The redux author's statement that TLA+ paper has mathematics too complicated for him to understand is unacceptable. The community should adopt SAM and develop more tools to help newbies implement it better. It is not necessary the responsibility of the author to do so or to explain it to people which are not willing to invest any effort to understand it by themselves.

VaseJS

@VaseJS

@raduab The post in a while in this room. but whomever you are quoting is still correct. The proof of burden is still on JJ (or anyone willing to take the reins). That is how the dev world works. Mathematics being to complicated is a true statement for the author of the comment as they have no need to explore an idea when they themselves already have one. It will not be until there are enough non-trival projects out there that SAM will be taken serious. This is the same way TLA was adopted by AWS. It started with person, then from that person to a small team, and after success, that team to another team. After repeated success, it spread. JJ does not have the same level of clout as an AWS, Facebook or Google so of course the idea won’t spread as fast, but the right project will give it credence amongst the dev community. It is the same hill, but a less powerful vehicle to get to the top.

but I must also agree with you that at some point the effort must be taken to understand and get the benefits of SAM. From the chat history, people are still experimenting with SAM but because people have to eat and keep a roof over their head, they don’t have the time to invest when they don’t know what their return on investment will be. So its up to you and others likel you, (me included), to use SAM in our projects and understand the pros and cons of SAM. Also, while its called the SAM pattern, it does not seem to follow proper or easy to follow pattern documentation. The pros and cons must be clearly understood and its still in the experimentation phase. After all new pattern criteria have been created/improved and enough people have used it, then an only then will it become a proper pattern.

VaseJS

@VaseJS

Below comes from Design Patterns: Elements of Reusable Object-Oriented Software and they describe how a pattern should be described. These things are not very clear/organized on the website and help others decide to use/try out a pattern. There is too much information on the internet the go through so it must be easy for any new user to pick and try out a pattern.

1.3 Describing Design Patterns

How do we describe design patterns? Graphical notations, while important and useful, aren’t sufficient. They simply capture the end product of the design process as relationships between classes and objects. To reuse the design, we must also record the decisions, alternatives, and trade-offs that led to it. Concrete examples are important too, because they help you see the design in action.

We describe design patterns using a consistent format. Each pattern is divided into sections according to the following template. The template lends a uniform structure to the information, making design patterns easier to learn, compare, and use.

Pattern Name and Classification
The pattern’s name conveys the essence of the pattern succinctly. A good name is vital, because it will become part of your design vocabulary. The pattern’s classification reflects the scheme we introduce in Section 1.5.

Intent
A short statement that answers the following questions: What does the design pattern do? What is its rationale and intent? What particular design issue or problem does it address?

Also Known As
Other well-known names for the pattern, if any.

Motivation
A scenario that illustrates a design problem and how the class and object structures in the pattern solve the problem. The scenario will help you understand the more abstract description of the pattern that follows.

Applicability
What are the situations in which the design pattern can be applied? What are examples of poor designs that the pattern can address? How can you recognize these situations?

Structure
A graphical representation of the classes in the pattern using a notation based on the Object Modeling Technique (OMT) [RBP+91]. We also use interaction diagrams [JCJO92, Boo94] to illustrate sequences of requests and collaborations between objects. Appendix B describes these notations in detail.

Participants
The classes and/or objects participating in the design pattern and their responsibilities.

Collaborations
How the participants collaborate to carry out their responsibilities.

Consequences
How does the pattern support its objectives? What are the trade-offs and results of using the pattern? What aspect of system structure does it let you vary independently?

Implementation
What pitfalls, hints, or techniques should you be aware of when implementing the pattern? Are there language-specific issues?

Sample Code
Code fragments that illustrate how you might implement the pattern in C++ or Smalltalk.

Known Uses
Examples of the pattern found in real systems. We include at least two examples from different domains.

Related Patterns
What design patterns are closely related to this one? What are the important differences? With which other patterns should this one be used?

Jean-Jacques Dubray

@jdubray

@raduab maybe your statement is a bit strong, but in general, especially with the Redux community, they see any orthodoxy as an attack to their coolness, unwilling to evaluate ideas on their face value. Today's trend in our industry are FP, RP and FRP. Anything outside of these boundaries is obviously wrong.

raduab

@raduab

@VaseJS thank you for your reply. People should use whatever tool/concept they think is best for their case. Myself I think that SAM is good for me, being based on pure logical concepts which are also the base of computing. Others may want to use a concept or tool which does not necessary have a community around it and which just works without any further intervention and doesn't depend on anything. Of course that more use cases would be welcome for new people to better understand the architecture or its application fields , but I think this should be the subject of a book instead - or a blog. (BTW, JJ already approached most of the points in your requirements for proper describing a pattern)

VaseJS

@VaseJS

They may be mentioned but they are not easy to see/well organized at the moment. This makes it harder for people to pick up. I love SAM this far but still have a hard time really putting it together. Some of the concepts need to be broken down further for those of us who don't have as much experience or who are just not as smart as the author. There is room for improvement and as you said, the more use cases, the better

Carlos Galarza

@carloslfu

Hi, what do you think about using statecharts and XState for UI development, is this approach similar to SAM in some way?

Jean-Jacques Dubray

@metapgmr_twitter

Carlos, thank you for reaching out. I used to be a big fan of Finite State Machines (of which statecharts) is an optimization. I started my career in Industrial Process controls using programming languages like Grafcet (which is statechart based). I spent about 20 years trying to apply the FSM semantics in a business setting (business process management, API orchestration...). The main difference between FSM/statecharts and TLA+/SAM is that in FSM the action decides the end state. In SAM, the action proposes a series of changes to the model and the state is then derived after the mutation. In other words, I believe the semantics of state machines are way too rigid and it is better to derive the control state after the model mutation have been executed. The succession of action-state-action-... is observed, and should not rigidly be defined.

I don't believe that FSM/statecharts scale in scope.

Last but not least, SAM has the concept of next-state-predicates that are a much better solution than sagas. Not sure if xstate relies on sagas or not.

Jean-Jacques Dubray

@metapgmr_twitter

@carloslfu happy to continue the discussion if you need more details

Carlos Galarza

@carloslfu

Interesting, thanks @metapgmr_twitter.

Where communities thrive

People

Repo info

Activity