## Where communities thrive

• Join over 1.5M+ people
• Join over 100K+ communities
• Free without limits
##### Activity
Jean-Jacques Dubray
@jdubray
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

Jean-Jacques Dubray
@jdubray
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\
brusand
@brusand
Thé more i see your code thé more i am conviced .
Jean-Jacques Dubray
@jdubray
Now last part is the model:
home.bio = {} ;
home.bio.id = 'bio' ;
home.bio.title = 'Biography' ;
home.bio.title1 = 'Michel Duran is a Franco-Canadian actor, director and producer' ;
you see the id? each component will have a different id, just like any button, link, ...
Happy to share more privately
Again, I don't code for a living, so I am ok if people laugh at my code
but I have been coding for the last 35 years... starting with my first commercial product at age 16 on an Apple ][
now the main menu has the same references:
home.menuItems = [{link: "#films", label: "FILMS"}
,{link: "#ontherun", label: "ON THE GO"}
,{link: "#contact", label: "CONTACT"}
To be fair, this I learned from Facebook. JSX is nice but personally I find it a bit of overhead. Of course with this kind of code you need to make sure you escape your inputs, but that's a very small price to pay for the flexibility of the code.
Jean-Jacques Dubray
@jdubray
As I said before, I been building Model-Driven Software as far back as 1993 with my students at ESIL in Luminy, so I know a thing or two about code generation.
In terms of reuse, code generation tends to be a bit better than libraries because we can generate exactly what we need from a base. In a library you only get the base and you have to make sur the right paths are enabled to support different use cases. Code generators beat libraries any day, but you can't deploy them everywhere. HTML is DSL, that's why it works so well here.
Stardrive ENGG
@HighOnDrive

@brusand Just wanted to chime in and say that the right reactive loop pattern and then modularization are most important. Everyone hypes components yet they are only there to make up the real estate of the UI with widgets. These widgets can be simple DIVs or stateless functions done with any DSL of your liking, however using them as a place to put all logic functionality is not smart.

What I think works best is to first have a good idea about what you want (not just blindly follow the hype) and then extract all logic, UI partials and control state out into separate modules. Then use components (and even Cycle.js drivers) ONLY as adapters (just essential intermediares between the external world or the vDOM, etc).

What that lets you do is pin your modularized functions to the components and drivers in the most decoupled way possible. That way the technology backing the components can be swapped out and all your modules (the meat of your app) are not in a hostage situation (at the mercy of the next great late framework).

This strategy IMHO is also important if we are going to supersede frameworks. So in a SAM solution I would have modules for each stage of SAM, then wire them together in the adapter shell components in the most transparent way possible.

Actually, even the not-terminal wiring functions that wire up the terminal functions should be in modules. Components should remain as empty as possible.

Jean-Jacques Dubray
@jdubray
+1M

yes, exactly:

use components (and even Cycle.js drivers) ONLY as adapters (just essential intermediares between the external world or the vDOM, etc).

Components should remain as empty as possible.

It's also you are more free to move that logic where it makes the most sense. React is client heavy, but it does not have to be that way at all. I favor a lot more balance with the server, though I can appreciate why Facebook is trying to use as many CPU cycles on the client. That kind of architecture does not work for everyone.
If you have tried to write some isomorphic code with React, that is a complete nightmare, when with SAM it is a complete piece of cake (at least the SAM implementation I build which is not Framework based)
Stardrive ENGG
@HighOnDrive
@jdubray Strategy is important if we are to survive the framewars! Have been away but following the exciting developments with SAM. I think getting SAM into the Flux-challenge is a great way forward :+1:
Jean-Jacques Dubray
@jdubray
agreed
Jean-Jacques Dubray
@jdubray
@HighOnDrive I would like to quote your previous comment on the view in the SAM tutorial. Would it be ok. Could we connect on linkedin?
brusand
@brusand
@HighOnDrive yes totally agréé with you, actualy with type script ans angular 1 ans qui router we czn organise code like login.module.ts , login.route.ts, login.view.tpl, login.contrôler.ts. .... with sam, we could have login.modèle.ts, login.state.ts, login.action.ts, all bases on. Dépendance injection. I ll post a link on a simple projection
Project
Stardrive ENGG
@HighOnDrive
@jdubray Sure, use the quote, cheers!
Stardrive ENGG
@HighOnDrive
If possible give me a preview, thanks.
Jean-Jacques Dubray
@jdubray

@HighOnDrive I was thinking something along the lines of:

A good Front-End Architecture should allow you to pin your modularized functions to the UI components in the most decoupled way possible. That way the technology backing the components can be swapped out and all your business logic are not in a hostage situation (at the mercy of the next great late framework).

would that be representative of what you were saying?

Stardrive ENGG
@HighOnDrive
@jdubray Just in from my day, like what you have distilled from the point I was making :+1:
Jean-Jacques Dubray
@jdubray
sure, thank you. Do you want to be quoted as HighOnDrive or with your real name?
Stardrive ENGG
@HighOnDrive
Use my real name, "High On Drive" is the title of a song I wrote for my prog rock band Stardrive Engineering :smile:
All the bands songs have the "Rocket Launcher" theme :rocket:
Jean-Jacques Dubray
@jdubray
Ah ah... you can't dislike SAM then. What it your real name?
Stardrive ENGG
@HighOnDrive
Thomas J. Buhr, did you get the linkedin connection from me?
Jean-Jacques Dubray
@jdubray
Yes, I did thank you!!
Bor González Usach
@bgusach
@HighOnDrive programming rock band? :D you take this business seriously!!
Bor González Usach
@bgusach
Got a question, how can actions be pure functions if they can call third party APIs which may not be pure? That is not quite the definition of pure functions...
Bor González Usach
@bgusach
And, moreover... they just produce side effects... that is the opposite of function purity
Jean-Jacques Dubray
@jdubray
they are pure fonctions with respect to the model
It is only with respect to the model
Bor González Usach
@bgusach

Uhm... I don't find it very intuitive to be honest.

Your idea might be brilliant, but I really can't understand it properly. You talk about pure functions (that return nothing and can perform almost any action), then the equations that describe your model have this term M.present( A(data) ), which I can't understand since the action functions return nothing. I also find kind of confusing that the SAM acronym stands for State-Action-Model, but when I take a look at your examples, I can see there is a fourth element called view (and so far I cant get my head around about the idea that state and model are different things, but maybe because something has not clicked yet in my brain)

I don't know, I am no specialist in this domain and maybe I'm trying to bite more than I can chew, but I think you have to make your material more didactic. Just my respectful opinion.

Jean-Jacques Dubray
@jdubray
Yes, your point is valid, the difficulty comes from expressing a reactive loop from an expression. Logically the view is computed from that expression. However, the pattern is reactive so it is the action which calls the present function, which can be viewed (and probably should be) a closure on the model.
All actions as structured as:
function action(data,present) {
var data_ = purefunctionAction(data) ;
present(data_) ;
}
And for the model:
function present(initialState) {
var model =initialState  ;

return ( function (data) {

... implementation of the present method ...
} ) ;

}
Jean-Jacques Dubray
@jdubray
Again, there is only so much you can express in a single expression, hopefully it still helps to understand the pattern.

I think you have to make your material more didactic.

yes, but that only happens over time, as people ask question and I understand where the disconnects happen

The View is the "State" representation. It is totally subject to the "State", it cannot stand on its own. I believe that has been one of the root cause of all MVX patterns, it is best to think in terms of business logic only because the view has none, that's why the pattern is not called VSAM (disclosure doesn't sound as good). That being said, V, the state representation, can actually be anything, SAM is really the pattern.
Stardrive ENGG
@HighOnDrive

@bgusach Progressive rock band and then a programming rock band in the form of a software project, best of both worlds :smile:

I understand where you are coming from about not finding SAM the easiest think to understand. Myself I'm here because I have discovered a pattern myself and find them very useful in managing complex reactive flows.

For sure there is a real need for a pattern to emerge that supersedes the half-full boiler plate oriented narrow boxes that frameworks try to lure you into, until you discover that circles just will not fit into squares, much to your dismay and against all the hype.

For me the SAM acronym itself makes sense because state drives all actions which affect models. That's how it lines up with how I define and use control states anyways.

Stardrive ENGG
@HighOnDrive

I think a nice top to bottom comparison table with one column per pattern/framework would be a helpful way to see the purpose of SAM. Just a succinct breakout of how different options handle the reactive loop and interact with the model, be it on the client or the backend.

Then after that is clear then various ways of wiring can be highlighted. Then finally code examples follow from that. The SAM pattern becomes lost in the shuffle so to speak if implemented in a specific wiring option before the comparison table is acturately presented.

This whole flow of revealing what SAM is follows a model (comparison table) then state (resulting wire options) then view (wired up code samples) format as well.

Jean-Jacques Dubray
@jdubray
Thank you Tom. I have actually the first table for React: http://jdubray.github.io/sam/#react
@gunar also shared an interesting video from the React Conference which started at ... V = f(M) and went on to compare React with other frameworks. https://www.youtube.com/watch?v=Pm0uwncSCo4&feature=youtu.be&t=14366