Until now, with what I understood I try to have :
A single model that store the entire app "state"
In each "SAM" components : some actions and views.
Each "SAM" "parent" components pass to each "childs" components their relevant part of the model.
What I try to understand now is how to correctly do the equivalent of the "model.present" in each childs components and pass it to the parents (that will maybe do some additional validation). Then, when model update has been done, how to pass new relevant data to each childs components.
But my way of thinking certainly still need some improvement to fully understand and be able to use the SAM pattern.
(I hope there isn't too much information and that what I say is understandable... there is so much that I need to wrap my head around that I have many questions and each solution I find is followed by other questions/issues :p)
mods/*.js (ES6)
What I try to understand now is how to correctly do the equivalent of the "model.present" in each child components and pass it to the parents
An action can choose which model it presents to. For instance the action wired to the submit button (or cancel) of a form can be calling the parent model.present({with_the_entire_form_data})
I will have in fact all the elements of the pattern running in the browser. And certainly will do something like requesting the API (a CRUD API essentially) just after data validation and updating the model accordingly to the API response (at least for a first try with no optimistic UI).
Concerning the fact that actions should not access the model, I understand it but... if you do something like that (based on the snabbdom example) :
ready: function(model) {
return h('div', [
'Counter: ',
model.counter,
h('br'),
h('button', {on:{click:function() { action.start(model.something); }}}, 'Start')
]);
},Does it means that I passed a part of the model to the action, or is it the right way of doing it ?
And finally, concerning what I said about multiples SAM "components", maybe I mixed everything in my head and I should have one "huge" SAM instance and break its elements in multiples elements of the same instance. I'll try to explain myself with an example : let's pretend that I have one page with a sidebar, a topbar and a content. I want to separate these elements in three "components". How should I do it ? A "master component" which contain the SAM instance "root", and the three subcomponents would extend this "master component" SAM instance ?
Trying to create some reusable components like we can create some reusable directive in angular is maybe a little bit difficult when beginning from scratch :p, but I'll try to do it anyway :p
Does it means that I passed a part of the model to the action, or is it the right way of doing it ?
yes, that's the right way of doing, it's better to pass the parts of the model you need via the view. Since you are running the entire instance of the pattern in the browser, it should not be a problem.
I should have one "huge" SAM instance and break its elements in multiples elements of the same instance.
Yes, you should use one "big" instance, though each parts can be broken down (especially the model). Child instances are only for self-contained elements like forms and wizards.
I want to separate these elements in three "components". .. a "master component" which contain the SAM instance "root", and the three subcomponents would extend this "master component" SAM instance ?
You'd have many actions
One model with 3 subelements (depending on how complex your header/footer are.
You'd have one state function which will control how the state representation (aka view) looks like
I'd organize the view components in a "theme", the idea being that you can replace the them by another one (that's key), if you cannot do that, you are doing something wrong. You could have a mobile theme and a web theme for instance.
I fixed the link
When you say:
var receiveUpdate = function(model, update) {
...
return model;
};that's pretty much how a reducer works. There is no particular need for it.
model.present function. Aside from being function(model, presentedData) vs model.present = function(presentedData), it is essentially the same thing.
In summary, distributed reactive programming is an open challenge. Existing reactive
languages take into account distribution in the sense that they are capable of transmitting
events or propagating function calls among remote hosts that independently
run a reactive system. In this way, however, consistency properties, locally enforced by
a reactive programming system, are not guaranteed over reactive data flows that cross
hosts [2]. We show that this limitation can lead to serious errors in the behavior of applications.
Despite reactive programming having huge potential as a means to coordinate
complex computing systems in a simple way, it struggles to succeed in this context.
- there are safety conditions (states you must not reach, the plane is landing and the runway is not clear)
- some actions are now allowed (dispatch / present)