Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP

Loading…

The example app leaks zombie App views #45

Closed
asparagino opened this Issue · 7 comments

5 participants

@asparagino

The bones example app creates a new App view for every view that subclasses Main. This leads to additional event handlers being attached and executing each time a new view displays. So while the example does work, it leaks resources in browser and isn't an ideal foundation for a real app.

There's a good description of the problem and one possible solution in the following link.

http://lostechies.com/derickbailey/2011/09/15/zombies-run-managing-page-transitions-in-backbone-apps/

I'm sure this would take a knowledgeable bones / backbone developer only a little effort to fix, but as I'm new to both frameworks it took me a little time to figure out and fix the problem before I could move on to my own code.

@springmeyer
Collaborator

@yhahn - thoughts on this one?

@AdrianRossouw

I checked this out, and the OP is correct on this one. We create new views in the router, but we only ever remove the DOM elements when we re-render the pages.

I'm pretty sure it is even occurring in tilemill, and other bones projects.

@springmeyer
Collaborator

@Vertice - how much memory do you think is potentially being leaked? Do you see any easy workarounds?

@asparagino

As well as the memory being leaked, there's also the potential side effects of each event listener firing multiple times and continuing to listen long after a developer would expect it to be dead.

  • For instance, if zombie views bind to the same model or class of UI element and all listen to the same event you can end up with that event happening a lot more times than you expect. This will tend to slow the browser clients down the longer a page is open.

  • It also opens up a class of bug that I haven't seen but could be hard to spot during testing and pretty devastating in the wild - if you were ambiguous with your button naming, a developer might innocently assume hitting a "#confirm" button on their new CreateView might not trigger a "#confirm" event on a previously displayed DeleteView... but it could. Testers would have to go through the views in the right order to trigger the bug and spot the hidden side effect, as each view would work when tested alone.

Brains!

@AdrianRossouw

I ran into the case @asparagino mentioned above.

My main view was setting up some navigation buttons outside it's own element. When it would route, the old navigation button view (and the event bindings) were still there, even if it re-rendered the markup. This meant that every time the button was clicked it would get an additional handler that triggered on the next click.

I think upgrading to backbone 0.9.2 might help here in some regards, since they added View.undelegateEvents(). I'm experimenting with firing $(this.el).undelegateEvents directly.

@makara

You only need 1 App view on the page, right? I think you can do something like

makara/bones@4131d0a

I guess then the problem would be the Main views won't know anything about the App view. Any ideas?

@miccolis

This should be fixed now. Please re-open if I missed something.

@miccolis miccolis closed this
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.