sorry, I am an old MDSE guy (can't help it)
@gunar yes and no, because remember, unlike Redux / Sagas, SAM sequences precisely action-model-state. If you look at Redux thunks, they write a "script" regardless of the control state reached. That is fundamentally flawed. That is why I wanted to talk to Dan originally, because Redux is so close, but at the same time, it's leading people in the wrong direction. We are back to the usual action-oriented spaghetti.
Front-End Architecture is such a perfect use case for SAM, because precisely it is a state machine. That's why FEA failed for the past 40 years, because we all ignored the state machine beneath.
Because After A, B may not be allowed, you can't arbitrarily write it that way
Yes it's awesome not to have to worry about entering invalid states, but imagine a very complex app sending numerous actions, that'd trigger many timers. From a SAM perspective that's not a problem at all, but has performance costs on the browser. But I guess that's beyond the scope of this discussion.
Remember, you also don't have to follow the exact semantic of SAM if you know what you are doing. In other words, that's what we have been doing for decades, writing state machines as a series of actions. The problem is that we rarely know what we are doing and SAM provides just enough constrains to eliminate most problems without much overhead.
Algorithms tend to not require patterns like SAM, so I am not suggesting that we start using SAM everywhere all the time. I am saying however that SAM semantics (TLA+) work everywhere all the time, so when you see value over more "optimized code" you should go back to the basics of SAM.
Does that make sense?
Since I learned about TLA+, I have looked at ways to use the semantics as you code so you have less bug to analyze later...
I am lazy :-)
I'll never make that claim
I can't claim you can nest n-level, but 2-3 levels should be ok.
Would that work for you?
The way you describe it seems that I will use the actions from low levels in high level views. I wondering about composing views too. For example, I have a SAM components handling different things with different views and I need to compose then on a larger SAM component that orchestrate then.
@adonirammedeiros so you don't want your low level views/actions to know about higher order SAM cycles?
Hmm... perhaps the inner Model could be a part of the outer Model. Sharing parts of the Store.
you could do that - and I've done it before - if you give the node an id (e.g.
<button id="send">) and then attach all event handlers after view rendering (e.g. document.getElementById('send')). Remember to have unique IDs.
I don't see another solution atm. Either that or using global references.
@gunar, yes most of libraries create DOM Nodes via
createElement, and then with the DOM Node you just have to set onClick or append an event listener. The idea of the IDs is not very practical in my opinion... somehow you have to keep track of the IDs and then attach the handlers. Looks like more work and not so clean information workflow (normally you would like to append the handlers when creating the code for the view). I have found the minimalistic library hyperscript quite nice, and the virtual-bom library is based upon this, which makes easier moving from raw re-rendering to a virtual dom approach.
Wiring HTML to actions otherwise has nothing to do with SAM.
If we take a simple example, say a login panel:
If we take a simple example, say a login panel:
<input id="username" type="text" value="username">
<input id="password" type="password" value="password">
<button class="button" id="login">Login</button>
Your handler is going to look like that (assuming the function V = S(M) is computed on the client):
$('#login').click(function() {
var view = document.getElementById("view") ;
var session = $.post( "https://www.nomvc.com/actions/v1/logmein", { username: $( "#username" ).val(), password:$( "#password" ).val() } ) ;
session
.done(function( model ) {
view.innerHTML = state.render(model) ;})
.fail( function(data) {
view.innerHTML = state.render({error: "server error"}) ; })
}) ;
@jdubray your example is fine, but I really don't think that is elegant in a general case. Let's say we have a model with some items, and for each item you want to create a button: with the IDs approach you iterate through the model, generate the HTML string, then you attach it to your DOM top root node via
innerHTML and then once rendered, you iterate again through the model so that you know some IDs, fetch DOM elements by ID, and then append handlers. I really would not do that. It looks way easier just to generate the DOM nodes with createElementcalls, bind the events, and return the DOM object instead of a string. Anyway, as you have commented, this is not an architecture issue...
@gunar if my low level components know about high level components they become attached to the context and I lose component reusability. I think about components that know a little bit about each other, just to allow the composition. I looking for something like mithril (I know mithril is a framework and SAM is a pattern), hmvc or pac. I like SAM idea. I try to imagine how I can reuse components in different contexts with little to no "friction". Putting a lower level Model inside a higher level Model, can lead me to put a lower level Action inside a higher level Action and so on. Based on @jdubray example (if I understand correctly) I think the Action can be used like "public interface" of a SAM component.
@bgusach hyperscript is very interesting, yeah. Actually, React uses event propagation ("bubbling") so it only needs to attach events to the root node. I've coded a small example
@bgusach cool right? I never knew it myself. I've asked on twitter :P
you'll see that parts of the site are built from the same component (bio and films, then for each films, and so on)
How was that build following the V = f(M) model?
So first how we put mount all the components inside f():
+ theme.sliders(home.sliders)
+ theme.actors(home.bio)
+ theme.clearFix()
+ theme.actors(home.films)
+ theme.clearFix()
+ theme.trailer(home.trailer)
+ theme.clearFix()
+ theme.trailerInfo(home.trailerInfo)
+ theme.clearFix()
+ theme.trailer(home.trailerReel)
+ theme.clearFix()
+ theme.trailerInfo(home.trailerInfoReel)
+ theme.clearFix()
+ theme.trailer(home.trailerCalBalloons)
+ theme.clearFix()
+ theme.trailerInfo(home.trailerInfoCalBalloons)
+ theme.clearFix()
+ theme.trailer(home.trailerTheatre)
+ theme.clearFix()
+ theme.trailerInfo(home.trailerInfoTheatre)
+ theme.clearFix()
+ theme.trailer(home.trailerOmbre)
+ theme.clearFix()
+ theme.trailerInfo(home.trailerInfoOmbre)
+ theme.clearFix()
+ theme.trailer(home.trailerOntherun)
+ theme.clearFix()
+ theme.trailerInfo(home.trailerInfoOntherun)
+ theme.clearFix()
+ theme.callToAction(home.callToAction)
+ theme.clearFix()
+ theme.gallery(home.gallery)
+ theme.clearFix()
+ theme.contact(home.contact)
+ theme.clearFix()each component of course being a pure function
then focusing on the actor component:
theme.actors = function(a) {
a = a || {} ;
a.id = a.id || 'actors' ;
a.title = a.title || 'TITLE' ;
a.title2 = a.title2 || 'TITLE2' ;
a.title3 = a.title3 || 'TITLE3' ;
a.title1 = a.title1 || 'TITLE1' ;
a.p1 = a.p1 || 'SUMMARY1' ;
a.p2 = a.p2 || ' ' ;
a.p3 = a.p3 || ' ' ;
a.background = a.background || 'html/img/background/5.jpg' ;
a.actors = a.actors || [{}] ;
if (a.actors.length>3) {
a.background = 'html/img/background/5b.jpg' ;
}
var actors = '' ;
if (a.actors.length>0) {
actors = a.actors.map(function(actor){
actor = actor || {} ;
actor.name = actor.name || 'NAME' ;
actor.surname = actor.surname || 'SURNAME' ;
actor.img1 = actor.img1 || 'html/img/actor/3.jpg' ;
actor.img2 = actor.img2 || 'html/img/actor/hover/3.jpg' ;
var img2 = '' ;
if (actor.img2 !== undefined) {
img2 = '<img class="before" src="'+actor.img2+'" alt="actor">\n' ;
}
...
return ('<!-- ACTORS -->\n\
<section id="'+a.id+'">\n\
<div class="center">\n\
<!-- title -->\n\
<h2 class="title">'+theme.localize(a.title)+'</h2>\n\
<!-- actors -->\n\