Yes, correct. I think it is essential to separate this logic because the scope is very different and the former is highly reusable. Take the Change of Address example from the paper, the action takes a small dataset as an input (street, city,...) then calls the getPostalAddress 3rd party API, and presents the postal address to the model. That logic can be reused across models, you can even think 3rd party will start offering actions following a SaaS model. Then the model accepts the address, and persists it. Conversely, you could also think that some actions to be solution specific, while the model is enterprise wide. Your company is rolling out a new product in selected countries and therefore the action must validate that the data set matches these countries, while the model could accept an address from any country because some products have no restriction.
IMHO, it makes no sense at all to couple that logic the way Redux does it.
IMHO, it makes no sense at all to couple that logic the way Redux does it.
Hi @jdubray First thx for bringing the SAM pattern. I had a (very) hard time to understand the principles because I found the approach too computer-science-high-level-of-abstraction for me. I am more used to the ducks and pizzas from the gang of four :)
So, after weeks, I finally got it (at least I except to...) and it is really simple!!
Now I have a question about how to reduce the increasing number of automatic actions.
Let's take an exemple: in a MMORPG (I am building one) a player clicks on a vendor of the shop to buy something (I don't talk about model mutation for simplification here)
- player triggers openPanelAction --> state: shopPanelOpened
- nap triggers loadShopData --> state: loadingData
- loadShopData callback triggers handleShopData --> state: shopDataReceived
- nap triggers buildPanel --> state:panelBuilt
- nap triggers ...
- ...
The problem here is that I have plenty of states which share the same context (open a panel) and are not used by the rest of the app. So I am looking for a way to encapsule this.
You say that composition of actions is OK with C(data) = B(A(data)) but is it ok to do E(data) = C(B(data),A(data)) ? In other word is it allowed to trigger a sequence of actions in the same action?
In my opinion yes because it is still one effect built with several independent effects sharing the same context. Isn't?
If yes, can generator could simplify the number of states?
So the core idea behind SAM is that the application state/model mutation follows a flow: propose/accept/learn and I agree what you describe is definitely a way to implement it, actually we were having a discussion about that very topic this morning in the main sam room.
I would argue that what you are building, even though being logical leads to this kind of code:
I prefer pastas...
pasta lack the "ball" structure
The big question is really how do you deal with effects?
And I would argue that you can actually run a query in an action and propose the results of the query to the model to mutate the application state.
I do agree though that models are a bit weak in SAM, but the way you should probably implement them (specially when they are heavy like requiring a query) would be to have a local SAM instance that deals with the modal, from there you would trigger an action back to the parent SAM instance (something like submit, or with nap() if the action is automatic and requires the model to disappear).
SAM instances are very light weight. So there is no real overhead in adding a SAM instance just for a modal.
In the first case you don't need a separate instance and I would put the query (an effect) in the action, the action would present the results of the query, the model would update with:
showPanel = true
paneData = data
and the State function would render the panel accordingly
showPanel = true
paneData = data
and the State function would render the panel accordingly
that way you have "ball" effect
In case two, yes, you have to use nap() to trigger the query, but again, there is no need write some yarn code to keep track of the query state. I would only add some code for cleaning up the panel in case of timeout (the action never present the data).
Would that work for you?
In Multi Player games, SAM is particularly effective because all players can share the same application state and you never lose track of which action, from any player are possible, at a given point in time. The model acts as a critical section that processes only one action at a time.
Similarly, if there are any updates to the application state that need to be persisted, I would do it right there in the model rather than in nap(). Theoretically nap() is where it should happen, but IMHO, it creates too many opportunity for race conditions, i.e. the model is free to process a new action before the persistence can succeed or fail. IMHO, it's not worth it.
Are you aware of the SAM-SAFE middleware? https://www.npmjs.com/package/sam-safe
Yes, again, in theory you should, but in practice I believe it better not too, you should use nap() only for something that needs to happen once you reach a particular state that no user would be able to trigger for instance. In any case, I would not use it at all for queries and updates.
Let me know if you keep using SAM, I'd be more than happy to add you to the list!!
The main change I made is for semantic. For exemple State is Status. And I keep State to represent a Model State. Which is simply a plain object that I wire to the view (react in my case but work for anything else) with MobxJS
State() enables a complete decoupling of the view components from the application.
It's ok, you can use any name that suits you.
Please note that SAFE enables what I call "action hang back"
of course you can cancel a long running action (like a query) by presenting a cancellation to the model
It should be very helpful in your scenario
I have also encapsulated the action to have a dev tool which keep traces of the triggered actions. This way the main loop is complety pure. "If action A is triggered with model state B then next model state will be R"
In your case, that is essential for debugging/testing