Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    Mauro Mandracchia
    @M3kH

    Guys, this is indeed an really cool feature for Marionette and I'm really looking forward in start to implements in some my side projects, just to see how it work and performs with some real cases.

    Anyway, Really thanks to be away from the JSX, unfortunately they try to solve a problem so far from what they got from XHP, since hhvm is not a everyday case, I'm really happy to see emerging some alternatives in this way.

    I think the dom it self is generic speaking a better approach to represent ui's and app status. So far is really a big advantage don't try to solve it with the gap of other languages like php has, in dom.

    Mauro Mandracchia
    @M3kH
    Now I'm glad to all this, but in the same time a bit scared in when I can actually use this in production.
    Sam Saccone
    @samccone
    @M3kH you can use it today
    Mauro Mandracchia
    @M3kH

    @samccone Yes you are right, but there is some controversial aspects for trust on it.

    1) No cross browser testing, which vendors are supported? Same for dependencies, like html->vdom.
    2) No embraced vision for Marionette it self.

    Did you thinks this approach can be generic speaking more powerfull once is full integrated with a unique vision framework, whit some consolidate principles Backbone, give to us? And maybe get the vdom transpiler officially supported by the framework it self?

    Tiago Garcia
    @tiagorg

    hey @M3kH - the lib virtual-dom is using Saucelabs to provide a full chart of cross-browser testing -> https://github.com/Matt-Esch/virtual-dom

    you are totally right, it would be very interesting to do something similar here. I will have a look on this tomorrow.

    regarding question 2, I’m not quite sure I got it. we are currently trying to extend Marionette instead of modifying, in order to be less dependent on the parent classes evolution and so be more compatible with different Marionette versions
    Mauro Mandracchia
    @M3kH

    @tiagorg Yes I got, and I'm sorry to criticise this cool work!
    My preoccupation start to the fact this would not be part of Marionette but just an add-on, since this is the approach; I see the limitations it brings.

    For instance, I can clear see by the code that we do:

    "string tmpl" -> _.template() ->  template(data) -> string -- to -- dom --> diff and append;

    Now has I was used to distribute compiled templates on my CI just to make sure to save one step to the browser; IMHO should be like this:

    "string tmpl" -> _.template() + vdom -> template(data) -> diff and append

    In this way templates can be optimised before.

    IMHO this project should be or detached by Marionette it self and be one step before has replacement for string templates engs. Or embraced by Marionette has template engine. In this way we could really compare with new dom framework approach.

    Then looking around I found really interesting this library https://github.com/gcanti/uvdom try to take a look at it, maybe can be inspiring.
    I will try to do a prof of concept to implement mustache -> uvdom -> (your vdom engine) -> your tmpl();

    Tiago Garcia
    @tiagorg
    @M3kH you are correct about this limitation, it as far as I understand this is the only way to keep full compatibility with any templating approach - once Marionette is non-opinated
    just for the record there have been some thinking about using HTMLBars on a very similar regard and @jmeas was looking into it.
    Marionette’s default assumpion is that a given template will come (and renderize) as a String. As you can see here: https://github.com/marionettejs/backbone.marionette/blob/master/src/item-view.js#L89
    and there is also a whole component for that. Marionette.Renderer https://github.com/marionettejs/backbone.marionette/blob/master/src/renderer.js
    Tiago Garcia
    @tiagorg
    so maybe that would be the place to perform such early-stage optimization to VDOM as you are suggesting - https://github.com/marionettejs/backbone.marionette/blob/master/src/item-view.js#L68

    pretty much, modify _renderTemplate method to immediately VDOMize the template before applying the data

    I just couldn't see how can this be done generically, before applying the data, let’s say a solution that would work for any templating engine - because I believe the way each templating engine binds its data would be particular to each engine

    for instance, Handlebars has helpers, so before rendering a piece of data, Handlebars would internally verify if that name resolves to a helper, or an instruction (if, unless), because those are reserved words for Handlebars
    I have never tried but I believe that Handlebars would never allow you to have a data attribute named “unless” while this might be possible for other template engines…
    Tiago Garcia
    @tiagorg
    anyhow.. @M3kH if this is possible to be overcomed, it will surely be better than this current approach
    please let me know how your POC with mustache goes, I believe this has a great potential to improve this approach as well
    :)
    Mauro Mandracchia
    @M3kH

    @tiagorg Maybe HTMLBars is the best way to go and since would be part of ember.

    I would try anyway to see if the uvdom approach can be useful since can compile templates for mercury and mithrill and react, which in the end would mean you can choose your vdom render engine and diff algoritm. Let's see! Anyway good initiative :+1:

    Thanks for doing all this and maintain the discussion interest.
    Tiago Garcia
    @tiagorg
    yes! I think uvdom is very clever going forward, looking forward to see your work :)
    Jim Macaraeg
    @jimbriam
    wonder if anyone could help me get this working using requirejs
    Jim Macaraeg
    @jimbriam

    paths: {
    'jquery': 'libs/jquery/dist/jquery',
    'underscore': 'libs/lodash/dist/lodash.underscore',
    'backbone.marionette': 'libs/marionette/lib/backbone.marionette',
    'marionette-vdom': 'libs/marionette-vdom/dist/marionette.vdom',
    'backbone': 'libs/backbone/backbone',
    },
    shim: {
    underscore: {
    exports: '_'
    },
    backbone: {
    deps: ['jquery', 'underscore'],
    exports: 'Backbone'
    },
    "backbone.marionette": {
    deps: ['jquery', 'underscore', 'backbone'],
    },
    "marionette-vdom": {
    deps: ['jquery', 'underscore', 'backbone', 'backbone.marionette']
    },
    jquery: {
    exports: '$'
    },

    },
    is the config that worked for me

    Jim Macaraeg
    @jimbriam
    ahh, but it doesn't work with requirejs's almond
    Tiago Garcia
    @tiagorg
    Hi @jimbriam - I didnt test yet with requirejs. could you get it working?
    Jim Macaraeg
    @jimbriam
    Yea, it was working with requirejs, but stopped working in the production build
    once almond was enabled (turned off async loading)
    maybe its just the configuration, but haven't dived deeper into it.
    Tiago Garcia
    @tiagorg
    Hey @jimbriam - @samccone helped us big time introducing the browser/AMD version which is using a UMD wrapper. if you npm install the latest version, you should be able to get it on the “dist” folder, which is also available here: https://github.com/tiagorg/marionette-vdom/tree/master/dist
    so I would like to suggest you to use it instead and let us know if would it work now
    Jim Macaraeg
    @jimbriam
    should have some time today to test.
    Jim Macaraeg
    @jimbriam
    so, i'm stuck.
    i think the problem is that almond/requirejs isn't resolving what it thinks are relative paths https://github.com/tiagorg/marionette-vdom/blob/master/dist/marionette.vdom.js#L4
    Sam Saccone
    @samccone
    hmmmm
    never used almond before
    Jim Macaraeg
    @jimbriam
    the build.sh should package all dependencies minus underscore, backbone, andmarionette ?
    Sam Saccone
    @samccone
    that is correct @jimbriam
    it looks to the window for those
    Jim Macaraeg
    @jimbriam
    looks like, this will take some time to figure out. it probably requires some advanced requirejs/almond-fu which is beyond me at this point
    William Fortin
    @wfortin
    hi guys, i'm currently looking to use your VDom View but we use precompiled templates via a gulp task. Will that still work or i need to use _.template() as in the examples
    Tiago Garcia
    @tiagorg
    hi @wfortin , yes it should work with any template engine you want to. you just need to make sure you give your template function to the View as it would work with a regular Marionette.ItemView
    Jiawei Li
    @jiaweihli
    @tiagorg I'm not sure I understand how this works - if I call render() on a CompositeView, the children all get destroyed and rebuilt
    it seems to only speed up template rendering, which is rarely the bottleneck
    Tiago Garcia
    @tiagorg
    hi @jiaweihli sorry for the late reply.
    so is your VDOM CompositeViewusing all VDOM ItemViews?
    Tiago Garcia
    @tiagorg
    I believe this is a consequence on how CompositeView render() method calls attachElContent() which probably wasn’t rendered from the VDOM before - https://github.com/tiagorg/marionette-vdom/blob/master/vdom-mixin.js#L35
    Jamie Rolfs
    @jrolfs
    If I understand correctly, this doesn’t explicitly replace window.Marionette.ItemView and window.Marionette.CompositeView does it?
    Jamie Rolfs
    @jrolfs
    @tiagorg also, a little confused as to why the distributables in this project are so big
    Tiago Garcia
    @tiagorg
    hi @jrolfs - that is because of the dependencies. hopefully the new versions of the dependencies will be smaller, I have always been looking forward to make this as small as possible
    and @jrolfs yes it can replace both views