Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • May 10 06:54
    coveralls commented #3689
  • May 10 06:51

    dependabot[bot] on npm_and_yarn

    Bump hosted-git-info from 2.7.1… (compare)

  • May 10 06:51
    dependabot[bot] labeled #3689
  • May 10 06:51
    dependabot[bot] opened #3689
  • May 08 14:53
    coveralls commented #3688
  • May 08 14:50

    dependabot[bot] on npm_and_yarn

    Bump lodash from 4.17.11 to 4.1… (compare)

  • May 08 14:50
    dependabot[bot] labeled #3688
  • May 08 14:50
    dependabot[bot] opened #3688
  • May 07 11:47
    coveralls commented #3687
  • May 07 11:45

    dependabot[bot] on npm_and_yarn

    Bump handlebars from 4.1.2 to 4… (compare)

  • May 07 11:45
    dependabot[bot] labeled #3687
  • May 07 11:45
    dependabot[bot] opened #3687
  • May 06 21:40
    coveralls commented #3686
  • May 06 21:21

    dependabot[bot] on npm_and_yarn

    Bump underscore from 1.9.1 to 1… (compare)

  • May 06 21:21
    dependabot[bot] labeled #3686
  • May 06 21:21
    dependabot[bot] opened #3686
  • Mar 30 15:57
    coveralls commented #3685
  • Mar 30 15:41

    dependabot[bot] on npm_and_yarn

    Bump y18n from 3.2.1 to 3.2.2 … (compare)

  • Mar 30 15:41
    dependabot[bot] labeled #3685
  • Mar 30 15:41
    dependabot[bot] opened #3685
dimtabu
@taburetkin

i must to be honest - never works with d3 before.
i am using svg as icons in my applications.
and i found out one thing: browsers "does not like" changes inside svg after it rendered in the dom.
i mean that this approach always fails to show svg:

SvgView.extend({
   tagName: 'svg',
   template: <....>
})

and this one works:

SvgHolderView.extend({
   tagName: 'div',
   template: '<svg> ... complete svg ...</svg>'
})

i do not investigate deepply this thing but maybe you will investigate it

heeplr
@heeplr
but nothing that actually uses marionettes' features (events, triggers, childviews) etc.
taburetkin: I see, thank you. So it's a common problem... I guess I have to find a way to render the parent and all child views completely before marionette attaches it to the DOM.
dimtabu
@taburetkin
backbone view by default does not have any render.
and in github you provided there is a d3 render implementation
on the other hand marionette has own render wich internaly do this: el.innerHTML = newhtml;
i believe that in svg case its not a correct way.
dimtabu
@taburetkin
@heeplr
new PlotView({ model: blobs }); this is not good idea in case if your blobs is actually collection
dimtabu
@taburetkin
sorry, i was to lazy to make it beauty.
heeplr
@heeplr
taburetkin: awesome it renders. thank you! Looking into that Mixin in depth now.
how else could I pass the collection to the childview of PlotView? as an option? the model is not actually used by PlotView, just passed on
dimtabu
@taburetkin
marionette has dom api.
the default implementation is innerHTML = newhtml
that is the reason why svg does not work out of the box with default marionette dom api.
for svg views in marionette you have to provide another domApi, compatible with svg
heeplr
@heeplr
well, it works in your example and afais you're just overriding View.triggerMethod to make it work. Looks clean to me.
dimtabu
@taburetkin

how else could I pass the collection to the childview of PlotView?

childViewOptions() {
  return {
    collection: this.collection
  }
}

also, by default model.collection will hold your correct collection (in most cases)

heeplr
@heeplr
I was about to test embedding <svg> inside <svg> to work around the problem. Maybe browsers treat that differently, but this solution looks much cleaner. If View events/triggers work, it's the way to go...
dimtabu
@taburetkin
and you are expecting dom/jqeury events on svg elements?
heeplr
@heeplr
But PlotView is a Marionette.View , not CollectionView. Am I allowed to pass collection: to a view? Will change events on the model trigger then?
dimtabu
@taburetkin
you can pass anything to a view or a collection view
heeplr
@heeplr
yeah, but will modelEvents: { ... } work with a collection passed to a View() and no model?
dimtabu
@taburetkin
collectionEvents: {}
heeplr
@heeplr
ahhh
very nice
dimtabu
@taburetkin
there is one important thing in fiddle i provide you
it not uses marionette render flow and there is instead d3 render.
so, in terms of marionette its a bad solution.
best solution will be to make some domApi to working with dom elements natively i supose.
dimtabu
@taburetkin

@heeplr
after some investigation i found out that there is a difference between document.createElement and document.createElementNS
backbone internaly creates view's element with createElement

you can check this interesting fiddle

it may be a clue
heeplr
@heeplr
hm, events and triggers don't seem to work as usual with BlobView
it works with .on('click', ...) like d3.js way
i can't seem to find out why it doesn't work. maybe it makes sense to do something like .on('click', { trigger marionette click event })?
dimtabu
@taburetkin
@paulfalgout what is the best way to set hook for view's region before:show ?
as i can see regions do not proxied their events to the parent view?
so, view.on('region:add', region => view.listenTo(region, 'before:show', view.beforeRegionShow) ?
or maybe there is another way?
Paul Falgout
@paulfalgout
Yeah hmm. Much of the auto-proxy things were turned off by default because it’s moderately expensive to do so, particularly when you don’t know the scale, but in a one-off situation I might just do this.getRegions() and loop over those to proxy any event. If I knew I could do that. region:add had recently been eyed as a possibility for removal, but you may have come up with the one usecase for the event. What you’re considering seems reasonable to me.
dimtabu
@taburetkin
ok thanks.
getRegions may work too but it seems that it will not catch dynamicaly added regions by default.
while there is add:region, remove:region i think i will stick with those events
dimtabu
@taburetkin

that was very beauty idea:

const SiteMapView = CollectionView.extend({
    template: `
        <% if (item) { %><%= item.menuName %><% } %>
        <% if (items) {%><ul></ul><% } %>
    `,
    tagName: 'ul',    
    initialize() {
        let items = this.model ? this.model.get('children') : this.getOption('items');        
        if (items && items.length) {
            this.collection = new Collection(items);
        }
    },
    childView() {
        return this.constructor;
    },
    childViewOptions(model) {
        let children = model.get('children');
        return {
            tagName: 'li',
            childViewContainer: children && children.length ? 'ul' : void 0,
        }
    },
    templateContext() {
        return {
            item: this.model ? this.model.attributes : void 0,
            items: this.model && this.collection
        }
    }
});

:)))

Peter Dietrich
@xosofox
Hi folks, I'm currently looking for pointers/ideas on how to manage translations/i18n with my Backbone/Marionette projects... I'm using underscore templates in html files (webpack + underscore-template-loader) and now I'm trying to figure out a good approach...
Any receomendations or experience?
Paul Falgout
@paulfalgout
Well we use handlebars-intl, but I think similar patterns could be applied to underscore. We add the translation files in a customer renderer applied to all views: https://github.com/RoundingWell/care-ops-frontend/blob/develop/src/js/i18n/index.js#L39
Peter Dietrich
@xosofox
I tried something along that line, but did not succeed. My template functions are already "compiled" by the underscore-template-loader, so I struggle to extend them.
My approach would be to add a "global templateContext" including a translatefunction.
I'm still running 3.5.1 on that project, so I'm not sure if your comment on marionettejs/backbone.marionette#2164 works.
Any example on how to make a translatefunction available to all templates via templateContext?
Paul Falgout
@paulfalgout
Our handlebars templates are also compiled. What’s effectively happening is:
setRenderer(renderTemplate);

const intl = {
  en: {
    welcomeText: ‘Welcome'
  },
  es: {
    welcomeText: ‘ Bienvenido'
  }
};

function renderTemplate(underscoreCompiledTemplate, data) {
  return underscoreCompiledTemplate(_.extend({}, data, { intl: intl[lang] });
}
@xosofox
Peter Dietrich
@xosofox
Do I understand correctly: You are basically "merging" all translated texts for the selected language into the data so it can be accessed in the templates?
Paul Falgout
@paulfalgout
yeah.. well handlebars has 2 ways to expose data to the template, but effectively yes
you could also inject template context helpers at that point
Peter Dietrich
@xosofox
Ok, got it... I'm trying to get it working
Paul Falgout
@paulfalgout
https://github.com/marionettejs/backbone.marionette/blob/v3.5.1/src/view.js#L206. looks like it is available on the prototype so like import View from ‘backbone.marionette’ then View.setRenderer(renderTemplateFunction);
Peter Dietrich
@xosofox
Ok, got "the basics" working, now I have a starting point for the i18n stuff around it. Thanks a lot!
dimtabu
@taburetkin
i suppose that its better to provide some func inside template context
in mixTemplateContextData
dimtabu
@taburetkin
  mixinTemplateContext(serializedData) {
    const templateContext = Object.assign({ L: toLang }, _.result(this, 'templateContext'));
    if (!serializedData) { return templateContext; }
    return _.extend({}, serializedData, templateContext);
  }

then in any template you can do

template: _.template('<%= L('text to be translated') %>'))

something like this

dimtabu
@taburetkin
@paulfalgout Hi! May i ask you how exactly you are testing mn benchmark?
Paul Falgout
@paulfalgout
well at one point we were using benchmark.js but those got behind. There’s also a couple of jsfiddles we were using and then js-framework-benchmark. But nothing that’s automated
Chris Bricker
@tallbrick
Looks like v5 is in the works. What sort of things can we look forward to?
Paul Falgout
@paulfalgout
@tallbrick it’s still in the very early stages but the main points are that it will open the door to non-destructive view renders where a view could re-render without destroying/reconstructing children. jQuery and Backbone will no longer be a dependency though they will both continue to be supported for sure, but it opens the door to other various forms of data and DOM rendering strategies. I suspect Backbone at least will continue to be the communities preferred data layer, but it won’t be required. v5 should be configurable to be mostly backwards compatible with v4.