Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Sep 01 03:57

    dependabot[bot] on npm_and_yarn

    (compare)

  • Sep 01 03:57
    dependabot[bot] closed #3691
  • Sep 01 03:57
    dependabot[bot] commented #3691
  • Sep 01 03:57

    dependabot[bot] on npm_and_yarn

    Bump tar from 4.4.8 to 4.4.19 … (compare)

  • Sep 01 03:57
    dependabot[bot] labeled #3694
  • Sep 01 03:57
    dependabot[bot] opened #3694
  • Aug 21 20:40
    amegahed opened #3693
  • Aug 10 23:41

    dependabot[bot] on npm_and_yarn

    Bump path-parse from 1.0.6 to 1… (compare)

  • Aug 10 23:41
    dependabot[bot] labeled #3692
  • Aug 10 23:41
    dependabot[bot] opened #3692
  • Aug 03 23:26

    dependabot[bot] on npm_and_yarn

    Bump tar from 4.4.8 to 4.4.15 … (compare)

  • Aug 03 23:26
    dependabot[bot] labeled #3691
  • Aug 03 23:26
    dependabot[bot] opened #3691
  • Jun 10 18:05
    paulfalgout commented #3077
  • Jun 10 17:58
    johnpmitsch commented #3077
  • May 25 02:41
    coveralls commented #3690
  • May 25 02:38

    dependabot[bot] on npm_and_yarn

    Bump browserslist from 4.5.4 to… (compare)

  • May 25 02:38
    dependabot[bot] labeled #3690
  • May 25 02:38
    dependabot[bot] opened #3690
  • May 10 06:54
    coveralls commented #3689
heeplr
@heeplr
i found backbone models don't support read-only attributes. This solves it and I guess it's not worth to create a backbone plugin just for this. (or is it?)
Paul Falgout
@paulfalgout
backbone wouldn’t take that. They’re pretty feature complete, or at least that’s the claim. They’re recommend a plugin.
heeplr
@heeplr
yeah, i mean PR for marionette
not sure but I think read-only attributes are quite common in APIs and I'm surprised there's no support for it, yet (in backbone and/or marionette)
Paul Falgout
@paulfalgout
marionette doesn’t extend model or collection
heeplr
@heeplr
it doesn't oh, nvm then
heeplr
@heeplr
i'm really stuck with error handling inside a child view of a collection. I'm doing "this.model.destroy()" inside my child view and it seems "modelEvents: { error: 'onError' }" isn't triggered when the DELETE API call fails with 500 status
...and the element is still removed from the collection
i searched up and down how to handle errors during collection API calls but everyone seems to use "model.destroy({ error: ... })" for every API call. Is there no way to have a global error handler for all requests?
I'd appreciate any slight hint very much :)
heeplr
@heeplr
the collection doesn't seem to receive an "error" event either
Paul Falgout
@paulfalgout
destroy removes the model from the collection immediately unless you pass {wait:true} so if you are not waiting for the endpoint success/fail then the model and childview are already destroyed and not listening to events that may happen after the destroy. So either you’ll need to wait or you can listen globally via however your backbone.ajax is setup. By default that’s jquery so that’d be https://api.jquery.com/ajaxerror/
heeplr
@heeplr
@paulfalgout indeed, waiting solves it. tyvm
thinking about it, that doesn't fully explain why the event doesn't bubble up to the CollectionView
at least in theory it should probably
Paul Falgout
@paulfalgout
Why
const myModel = myCollection.at(0);
myModel.destroy();
myCollection.get(myModel.id); // not found
// myModel 500.
heeplr
@heeplr
well, since the collection isn't destroyed. i didn't look into the actual bubbling mechanism
well, i have to wait anyway since I can't "undelete" a model after a failed API call
Paul Falgout
@paulfalgout
collection still exists, it just isn’t aware of the destroyed model unless you wait to remove it from the collection until after the server response.
heeplr
@heeplr
I think the model shouldn't be (finally) removed from the collection until the server responded with actual success/error... but otoh I can't really wrap my head around all this promise and async thingies, yet :-P
Paul Falgout
@paulfalgout
that is what { wait: true } is for
heeplr
@heeplr
yeah, and it's perfectly fine for deletion in my case. No asynchronity needed.
probably would took me the whole day to figure out if you didn't mention it
Paul Falgout
@paulfalgout
it is still async. the difference is effectively this:
model.destroy({ wait }) {
  if (!wait) {
    this.trigger(‘destroy’); // clear all listeners and remove from any collection
  }
  $.ajax(‘DELETE’, { 
    success() {
      if (wait) {
        this.trigger(‘destroy’);
      }
    },
  });
}
in both cases the delete is async. In fact { wait: true } does things slightly more async
heeplr
@heeplr
ah
yeah, just found out the "error" event isn't triggered with wait=true :-(
Paul Falgout
@paulfalgout
I don’t see why that would be the case
heeplr
@heeplr
i'm currently looking into it
my "collectionEvents: { error: 'onError' }" is called with wait=false, but not with wait=true on "this.collection.create()" getting a 422
Paul Falgout
@paulfalgout
well yes, now you’re talking about the opposite situation. You’re waiting to add the model to the collection until you know if it worked on the server yet. So if there’s an error.. it’s never added to the collection
heeplr
@heeplr
:( looks like I can't use this backbone feature then. i'll try with jQuery ajaxerror
heeplr
@heeplr
Still I don't understand why the (non-added) Model has to trigger the error event and not the collection, where create() was called
heeplr
@heeplr
aww, ajaxError() doesn't seem to support parameters so I can't pass the view to show the error in :(
heeplr
@heeplr
phew, it works when I "model.collection.trigger('error', ...)" manually in the collection.create() error handler.
dimtabu
@taburetkin

@paulfalgout Hi, Paul
What about HamburgerViewout of the box ?
do you personaly use such approach? can you share your experience a little bit, please

my "hamburger" view example
https://codepen.io/dimatabu/pen/qBjaavm
this time i did it in behavior, just for fun, but it seems that this is definitely should be a mixin

Paul Falgout
@paulfalgout
seems ok. It’s hard without a specific use case, but if you’re going to use this over and over again maybe it’s good? I’d probably solve this with a few nested views, but then I don’t know the use case.
dimtabu
@taburetkin
the use case is as simple as
<div>
<view1>
<view2>
...
<viewN>
</div>
in my live applications this is the 90% of views
dimtabu
@taburetkin
maybe it wiil be more correct to move this functionality in a special view
something like CustomViews = Mn.View.extend(...)
i don't know yet.
and drop collection supporting by default
my production variant of this behavior able to render html like this (just because of supporting collection)
pagination and advert views are custom views:
<div>
  <pagination view>
  <advert view1>
  <model view1>
  <model view2>
  <model view3>
  <advert view2>
  <model view4>
  <model view5>
  <model view6>
  <advert view3>
  <pagination view>
</div>
but this example is more rare than usual use case (simple hamburger without collection)
heeplr
@heeplr
Is there a way with marionette/backbone to add event handlers that won't trigger on child-triggers?
I have multiple nested views containing bootstrap collapse elements. In each view I listen to events: { "show.bs.collapse @ui.collapse" } (with @ui.collapse selecting only one element). The parent Views' event handler gets triggered when a nested View's event triggers which I want to avoid.
The best solution I found so far is, ignoring the event using something like "event.currentTarget !== desired_element" in the handler, but maybe there's some better way to achive that?
Paul Falgout
@paulfalgout
events is a backbone api. essentially you’ll want to stopPropagtion on the event in the child view as the bubbling is in jquery / the DOM
@heeplr
heeplr
@heeplr
hm, I tried that, too. The parent event is still getting triggered.
ah, it's triggered in onRender() and the parent got re-rendered, too. Changing the calling order changes order of events and both handlers running works now using stopPropagation. yay
@paulfalgout thanks!