Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Jean-Jacques Dubray
    @jdubray
    Does that make sense?
    Gunar Gessner
    @gunar
    "Simulate"? They rewrote parts of their software in TLA+ patterns just to better understand the system?
    Jean-Jacques Dubray
    @jdubray
    yes, this is what TLA+ is, it's not a programming language, it is a formal method to analyze code
    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 :-)
    Gunar Gessner
    @gunar
    Awesome
    Jean-Jacques Dubray
    @jdubray
    But again, that's not a way to write all your code.
    I'll never make that claim
    adonirammedeiros
    @adonirammedeiros
    @jdubray how do you compose larger SAM components with small ones? There's some way to do this?
    Jean-Jacques Dubray
    @jdubray
    It works at the view level, view can call actions at any level. comp
    I can't claim you can nest n-level, but 2-3 levels should be ok.
    Would that work for you?
    adonirammedeiros
    @adonirammedeiros
    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.
    Bor González Usach
    @bgusach
    @jdubray, I think you did not understand what I said about attaching handlers to DOM Nodes built by string concatenation... anyway, it is just an implementation detail for HTML, nothing to spend too much time on.
    Gunar Gessner
    @gunar
    @bgusach you could try checking out how react does it. perhaps even Inpecting a React app through Developer Console could give you a hint. I'm curious too so let me know if you find something interesting.
    @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.
    Gunar Gessner
    @gunar
    I (we?) haven't yet thought about SAM "components" , but rather as an architecture for whole apps.
    Gunar Gessner
    @gunar
    @bgusach I think that because React uses var el = createElement - instead of creating elements on the fly with strings - it can do e.g. el.onClick = ...
    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.
    Bor González Usach
    @bgusach
    @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.
    Jean-Jacques Dubray
    @jdubray

    @bgusach I was responding to this question:

    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.

    This is where code generation makes it rather trivial compared to handcoding it.

    Wiring HTML to actions otherwise has nothing to do with SAM.
    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"}) ; })
        }) ;
    Jean-Jacques Dubray
    @jdubray

    The State element is generating both the state representation with the knowledge of the actions. So there is no conceptual difficulty in aligning the two.

    id="login"

    can be generated not handcoded

    Bor González Usach
    @bgusach
    @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...
    adonirammedeiros
    @adonirammedeiros
    @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.
    Gunar Gessner
    @gunar
    @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
    Bor González Usach
    @bgusach
    @gunar, oh that is quite neat... I never took profit of event propagation. Thanks ;)
    Gunar Gessner
    @gunar
    @adonirammedeiros I'd have to think about that.
    @bgusach cool right? I never knew it myself. I've asked on twitter :P
    brusand
    @brusand
    For components maybe typescript and modules could help for componentisation .
    Jean-Jacques Dubray
    @jdubray
    @brusand let me take an example I worked on recently. If you to to http://www.michelduran.com
    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

    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: "#theatre", label: "THEATRE"}
                    ,{link: '#gallery', label: "GALLERY"}
                    ,{link: '#bio', label: "BIOGRAPHY"}
                    ,{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