1/ I would say it complements/augments them. It is strictly compatible but supports a more practical management of the application state, especially when the application state is complex, subject to many different actions.
2/ I am not sure how they can be used at the same time, for sure SAM supports a child/parent relationship and one of the children would be a child (or the parent) as long as XState would enable calling an intent (a wrapped action in SAM). An intent is a simple function so I don't see any difficulty. XState should be able to weave these functions in its programming model. I would not try integrating XState and SAM directly though it might be possible (say XState as an acceptor updating the currentState of the model). I am not sure how the View would react to that kind of integration. I would think that SAM is enough and better than XState but I am biased. XState has enjoyed some success, I suspect because of the graphical tool. My main issue with State Charts is that they do not scale in scope, at some point the State Chart becomes too big to maintain.
3/ What framework do you plan to use for the GUI?
setRender : sets the render method and that's it, no parameter defintion. In the change log it says other things 1.4.1 Changes setRender to accept only one function (or two). This has to be consistent. Which are the setRender accepted parameters? And what do they do exactly? For example for the 'retry' function there are more details for parameters retry { delay, max } when specified, it will retry invoking an intent in case of an unhandled exception up to max times and after delay ms.. Also a more comprehensive explanation of the lib's functions will be very welcome. I think I'm not the only one who struggled. Thank you.
sam-actions.js file from the lib directory and not into the sam.test.js file (more of this later below). There I could see starting from line 23 that the setRender function is transforming its render parameter, if it's an array, into a function of the state which returns the result of the function represented by the first item of the array which in turn it takes a parameter (the state) or the result of the function represented by the second parameter which is another function of the state parameter. If the setRender parameter is not an array, it simply returns the result of SAM({ render: F(render) }) which I don't know ATM what it does... Oh boy, that took me some time to figure... Here is the whole code I'm talking about: setRender: (render) => {
if (Array.isArray(render)) {
const [display, representation] = render
render = state => display(typeof representation === 'function' ? representation(state) : state)
}
SAM({ render: F(render) })
},F function is doing or what it's used for. Just looking into the sam-utils.js file I can tell that it takes one or two parameters, with the second defaulting to a null function, and it returns the output of the function from its first parameter (render in the case of setRender function) or the output of a second function if it is received as its second parameter. At this point, I don't know where to dig more for an answer regarding the F function. Maybe I can understand this after investing more time into deciphering the code, but this also should be documented somewhere or at least you should add some JSDocs. Another problem is naming things in your lib. I know that naming things is one of the most difficult problems in computer programming, but still, just F is making me remember javascript obfuscators... Speaking of this, diving into the sam-utils.js file I see a lot of other similar examples. I struggled to understand what E function is doing, after finding it used in the sam.test.js file where you first instructed me to look for answers to my questions. I could understand the code - probably - but still, can't understand its usefulness (not that I think it is not useful, but don't know what it's used for and in what situations exactly..)
// Optional chaining implementation
I'm trying to use the SAM pattern in a project I'm working on. I have been trying to figure out what would be the best balance between the client and server.
I have other clients in addition to browsers and I would like to provide one API that all clients will use. Usually I would expose a REST api that could be used to fetch the initial information and a websocket that would send updates to the information in real time to all clients.
Do you have any examples of this kind of use case with SAM? Should I render multiple versions in the stateRepresentation for different clients?
For example let's say the app was a book reading app that also allows people to read together.
Each client should be able to read their own book at their own pace. The model needs to keep track of each clients book and which page they are own.
Clients could also read together. Their book and page is synced. Any client can change the page and all other clients who are reading together will also get the page change.
There are also ebook readers which need to get the book in their own format instead of html.
There are also ebook readers which need to get the book in their own format instead of html. nothing prevents you render the state representation on the server, for HTML I would rather do it in the browser, for others the rendering can also be done server-side, it's just more difficult to have a fluid UX (perhaps).
In this "Book reading app" there is always only one copy of each book. As the books are precious artifacts there is a librarian who does the actual physical page change. This "Librarian" exposes an API for changing the pages. Internally the librarian could be implemented in other languages than javascript.
I have been trying to figure out how to link together the user session model, group model and the Librarian API.
Would it be ok to call the librarians from the model as you mention CRUD operations should be in the model? The model would then either update the page number or mutate to an error state depending on the response. Then the nap could be used to sync this to other models by sending them actions.
For group sessions there would be a similar nap sync and some kind of join/leave actions that would determine which user models should be updated.
I know this is not really about SAM and more about how to organize the program in general. But I'm just trying to rough out where different things fit in the SAM pattern.
For some reason it feels a bit crowded to have multiple loops that are updating each other. Kind of like looking at this kind of watch mechanism. Each part has a specific purpose and reason for being there. But it looks scary when you aren't familiar with it yet. https://www.realmenrealstyle.com/wp-content/uploads/mechanical-watch.jpg
It seems to me that the proof/simulation that TLA+ offers cannot scale to a large code base (at a minimum without some automatic translation between code and formal specification). It was my hope at some point that the TLA+ folks would explore that path, but I guess, it's not yet prioritized.
@jdubray as an aside, that's something I heard discussed in this podcast episode https://signalsandthreads.com/compiler-optimization/ - the guest on here has an academic background in software verification, but makes the point that the burden of writing software + specification is still too much for most programmers, especially as the software changes
Hello everybody and happy new year !
@TimoteusRuotsalainen here are my 2cts for modeling the book app with SAM components.
The model :
I would modelise a room with:
- a book state (id, current page...),
- hasFinishedThePage[] an array for storing the state of each reader
The librarian could be a NAP (a service with its own rules reacting to a new model state). If the NAP condition is triggered (for exemple, all the reader of the room has finished the page), then it will trigger turnPageAction.
The state representation could be :
- the raw text
- page id
and what ever data not bound to the various client (reader, browser, voice synthetizer, etc.)