Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Sep 16 01:39
    coveralls commented #3672
  • Sep 14 15:23

    paulfalgout on master

    docs: Fix typo (remove colon) (compare)

  • Sep 14 15:23
    paulfalgout closed #3672
  • Sep 13 23:09
    jhwohlgemuth edited #3672
  • Sep 13 23:08
    jhwohlgemuth commented #3672
  • Sep 13 23:06
    jhwohlgemuth synchronize #3672
  • Sep 12 15:18
    paulfalgout commented #3672
  • Sep 07 02:38
    coveralls commented #3672
  • Sep 07 02:36
    jhwohlgemuth opened #3672
  • Aug 21 15:35
    paulfalgout closed #3667
  • Aug 21 15:35
    paulfalgout commented #3667
  • Jul 10 21:38
    mainstreetmark commented #3631
  • Jun 18 11:39
    alexone077 commented #2200
  • Jun 18 11:39
    alexone077 commented #2200
  • Jun 06 13:18
    paulfalgout locked #3670
  • Jun 06 12:49
    thapaphon21731 commented #3670
  • Jun 06 12:42
    paulfalgout closed #3671
  • Jun 06 12:42
    paulfalgout closed #3670
  • Jun 06 11:39
    thapaphon21731 opened #3671
  • Jun 06 11:35
    coveralls commented #3670
Martin Lundberg
@marlun
Well, after all this work all that was needed was an upgrade of marionette and backbone.radio. I also had to spell correctly :) Thanks for the help!
John Michael Swartz
@graphographer
Can somebody help me to figure out why childViewOptions is being called on an empty collection?
or do I always need to check for the existence of the arguments to that method?
Paul Falgout
@paulfalgout
you can also set emptyViewOptions: {}
this is kind of a legacy behavior
I don't love it, but hadn't seen a complaint, and rather than introduce yet another breaking change.. but here's what's happening: https://github.com/marionettejs/backbone.marionette/blob/master/src/collection-view.js#L618
John Michael Swartz
@graphographer
Ah! Thanks @paulfalgout
dimtabu
@taburetkin
have an interesting conversation today in backbone room
about marionette
Paul Falgout
@paulfalgout
I suppose I don't quite follow, "everything detach/atach, OR everything destroy/render."
dimtabu
@taburetkin
well, i have some experiments with trying to keep some views as singletons
so, they created once and never destroys. and i have to do some black magic to implement detach/atach behavior instead of render/destroy in region
that was interesting but useless
Julians composite view is trying to apply detach/attach concept for child view instead of destroy/render concept which is default for marionette.
so, view can render some custom html without re-rendering children
i feel that this is not good idea but don't know why and don;t know how to explain, (but i can be wrong here)
dimtabu
@taburetkin
the main thing is... as i can see, that marionette region can be better, or even different.
Paul Falgout
@paulfalgout
attach/detach is doing mutation in the dom rather than doing it on a node prior to putting it in the DOM. that's significantly slower for large renders
dimtabu
@taburetkin
agree
Paul Falgout
@paulfalgout
I think region in v5 will be able to handle re-rendering without destroying children, but it will break compatibility with jquery to some degree
dimtabu
@taburetkin
actually, at this point i even do not know do i need this or not... it seems that just render/destroy is pretty honest and ok in most cases
but something new is always a good :))
Paul Falgout
@paulfalgout
yep I agree. I don't think I'll use it, but it'll be available. I think it opens the door for alternative renderers that could do bigger things
dimtabu
@taburetkin
Paul, can you give me link to performance compare table?
or point me where i can find this link
i mean against other frameworks
John Michael Swartz
@graphographer
@taburetkin I think the usual go-to is Stefan Krause at https://stefankrause.net/js-frameworks-benchmark8/table.html
dimtabu
@taburetkin
oh! thx
dimtabu
@taburetkin

can not get one thing, i am trying to extract backbone events into a separate lib
and some test makes me ill.
there is a chance that i understand it wrong, or....
here is my mocha test

it.only('callback list is not altered during trigger', function() {
  let counter = 0;
  let increment = () => counter++;
  let switchOn = () => emiter.on('event all', increment);
  let switchOff = () => emiter.off('event all', increment);

  emiter.on('event all', switchOn).trigger('event');
  expect(counter).to.be.equal(0);

  emiter.off()
    .on('event', switchOff)
    .on('event all', switchOn)
    .trigger('event');
  expect(counter).to.be.equal(2);
});

description and test logic taken from backbone tests
here is the link: https://github.com/jashkenas/backbone/blob/master/test/events.js#L458

please help me to understand.
i read the description as there should not be any changes in event callbacks list during one trigger run.
and if so, counter should be equal zero in the end of this test, but in backbone version it's 2.
why that happens?

dimtabu
@taburetkin
crap, after examining original test more carefully i found out that just make some typo, when rewriting this test
so, nvm :)
i should take a rest
dimtabu
@taburetkin
finally.
i've done with tests.
currently i have two separate libs
one - exact copy of Backbone.Events, with all backbone tests rewriten in mocha chai syntax.
and the second one is my own Events library which is fully compatible with Backbone Events and has the same backbone tests - all pased.
while i doing that i found out that backbone events has partial support for non backbone events.
i say partialy because it has some issue test against something with on method and those tests are looks to me not properly written. also listenToOnce currently not supported in backbone events on non backbone events instance.
my version of lib can handle that
also, after some thoughts i start thinking that both implementations are weak (mine and the backbone's one) in case of handling non backbone events.
and i dont realy know if its usefull at all?
i have a thought how it can be properly done but not sure it should
Paul Falgout
@paulfalgout
there are issues on backbone github somewhere about interop events
dimtabu
@taburetkin
yes, 3611
and there are two tests covering something
but, not almost, as i found out
John Michael Swartz
@graphographer
Hey friends! I have an interesting problem to solve.
I have a collection and a collectionView. The views in the collection view, however, are rendered from different (but intimately related) models than are in the collection.
So, as would be expected, when models are removed from the collection, the corresponding child views are not removed.
Ideas on how to handle this? a listener in the child view?
I have a method on the collection model that returns the view model, so maybe a collectionEvent listener on remove event
Paul Falgout
@paulfalgout
yep you'll have to manually handle that similarly to what you're suggesting
John Michael Swartz
@graphographer
what CollectionView method should I do to remove the child view?
Can I get a child view by its model, even if its model isn't a part of the collection view's collection?
I suppose I could do a findWhere
findByModel!
hmn, it couldn't find a view..
Paul Falgout
@paulfalgout
the findByModel is the issue.
John Michael Swartz
@graphographer
oh i see...
they're different models, just like i said they were...
i have to use the method i said i had to relate the collection model to the model actually used in the view
let's see how that goes.
aha! it works!
just for reference, here's the scenario:
collectionEvents: {
        remove(model, collection){
            this.children.findByModel(model.getOther()).destroy();
        }
    },
    childViewOptions(model){
        return {
            model: model.getOther(),
            showcase: this.stores.showcase
        }
    }
Paul Falgout
@paulfalgout
:+1: