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
Great job!
By the way, Wizar looks like an amazing idea!! I can imagine the potential!
@dagatsoin One more thing about your question on Action composition. So logically, actions cannot be composed, the flow is propose/accept/learn, you cannot trigger another action before the application state has been mutated. That being said, you can create "composite" actions, this is possible/easier to do because of the dataset signature of the present method. You can create composite actions through functional composition A(B(data)) or even C(A(data), B(data))... but you are not triggering multiple "actions" per se. You merely decompose and recompose a single action.
Thx for Wizar, I do my best :)
I understand the need to not trigger another action when model is still mutating. But I don't see how to compose action. Or maybe I am a bit lost in translation around your explanation. Have you got a simple concrete exemple of action composition ?
For example, does it fit the requirements?
const actionGiveMana = (manaPts, model) => {
//somelogic
...
model.present(data);
}
const actionHeal = (healPts, model) => {
//somelogic
...
model.present(data);
}
const actionCare = (manaPts, healPts, model) => {
actionGiveMana(healPts, model);
actionHeal(healPts, model);
//somelogic
...
model.present(data3, model);
}In the case of firing actionCarethe model will be mutated twice before the final effect. But in my mind, this is still a pure function because we can reproduce the same effect with the same initial model state.
An action represents semantically a proposal to update the application state in one "step", as a unit of work if you prefer. It is also a unit of authorization, given a particular state (battling, sleeping...) is an action authorized to be triggered. As such the "actionCare" is not valid, or at least you have to make sure that the actionGiveMana "step" is complete before you trigger actionHeal.
It's ok to pass the model as an input to the action, with the understanding that no mutation should occur there. The mutation occurs when the action invokes model.present.
It's ok to pass the model as an input to the action, with the understanding that no mutation should occur there. The mutation occurs when the action invokes model.present.
I would prefer see something like this if it makes sense to you:
var careData = actionHeal_(actionGiveMana_(healPts,model),model)
mode.present(careData)where actionHeal() and actionGiveMana() are the pure function generating the input to the present method
It would look like:
const actionHeal = (healPts, model) => {
model.present(actionHeal_(healPts, model));
}
All you can do is decompose/recompose the way the dataset is constructed, but logically only one action can present data to the model.
I mean, does it also mutate the model with model.present? Or simply return a data which will be valid for the model?
the values should be raw, no further calculation should be done in present()
yes, exactly
they could add their points too
this is like like a pipeline
The idea is that the model has the knowledge to update the application state
the action has the knowledge to validate events and do some calculation to present values that the model would understand
the view should have no knowledge of the model
Actions are like mini adapters between the view and the model
the view generate an event, the action translate that event into proposed values to mutate the model
but still the action does not know if the update will succeed
other conditions might influence the outcome of the intent
about the other concitions:
in my case, a player could have a spell (a debuff) on it which will be decrease the received heal point +3 . (the spell is a property of the model)
During the present computation, if the model detects some healpoints in the data set, il will minus it of 3.
As the action does not have to know if the player has a debuff, is it correct that this computation is done in the model?
in my case, a player could have a spell (a debuff) on it which will be decrease the received heal point +3 . (the spell is a property of the model)
During the present computation, if the model detects some healpoints in the data set, il will minus it of 3.
As the action does not have to know if the player has a debuff, is it correct that this computation is done in the model?