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 ?
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.
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.