marionettejs/backbone.marionette

(⊃｡•́‿•̀｡)⊃━☆ﾟ.*･｡ﾟ The Backbone Framework: http://marionettejs.com

heeplr

@heeplr

would that be worth a pull-request: https://gist.github.com/heeplr/b4ed41bbdf074a5c7f6ec77ece47df5d ?

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

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!

Where communities thrive

People

Repo info

Activity