I hope this piece of code is enough to understand the problem.
The issue is the following,
1) I load myView for the first time,
2) If I click on div#myId, the function myAction is triggered just one time as expected.
3) If call the method remove for rendering another view, the functiom myAction is triggered two times.
4) Then if I repeat the step 3) the functiom myAction is triggered three times and so on.
What could be the problem?
var myView = Backbone.View.extend({
// The DOM events specific to an item.
events: {
"click #myId" : "myAction"
},
myAction: function () {
// some code
},
remove: function remove ()
{
$(this.el).html("");
}
});
P.S.:
The DOM which is created to each render call is ok.
usually the problem here is that you're in some state where you're re-rendering views over a pre-defined element over and over again, without properly destroying the view, resulting in 'zombie' views. If you've defined an el in your view, and keep rendering said view on it, you will end up duplicating your events.
in jQuery for an example if you do this a couple times:
$(document).bind('click',function(){ console.log("document.click"); });
$(document).bind('click',function(){ console.log("document.click"); });
$(document).bind('click',function(){ console.log("document.click"); });
it will fire the event three times.
Take a good look at how you initialize your views, and most importantly how you render/re-render them.
what you have to do in your remove method is more something along these lines
remove: function remove ()
{
this.$el.remove();
this.$el.unbind();
}
Related
So Im new at backbone, and Im trying to make a single page app, Im using routes to manage certain things, and I want to remove a view when the user gets to another route
Im using this method to destroy the view
destroy_view: function() {
// COMPLETELY UNBIND THE VIEW
this.undelegateEvents();
this.$el.removeData().unbind();
// Remove view from DOM
this.remove();
Backbone.View.prototype.remove.call(this);
}
also this is my route element
Router = Backbone.Router.extend({
routes: {
'':'index',
'#':'index',
'events/*event' : 'events'
},
index: function(){
this.indexView = new VistaIndex();
},
events: function(params) {
if( this.indexView )
this.indexView.destroy_view()
this.eventView = new EventView({currentEvent: params})
}
});
the problem with this is that if I do this the app crashes, so what do you recommend me to do :)
Here’s how I do it:
Backbone.View.extend({
//some other view stuff here...
destroy: function () {
this.undelegateEvents();
this.$el.removeData().unbind();
this.remove();
//OR
this.$el.empty();
}
});
First we want to make sure we’re removing all delegated events (the ones in the events:{"event selector": "callback"} hash). We do this so we can avoid memory leaks and not have mystery bindings that will fire unexpectedly later on. undelegateEvents() is a Backbone.View prototype function that removes the view’s delegated events. Simple.
Next we want to cleanup any data in the view object that is hanging around and unbind any events that we bound outside the events hash. jQuery provides a removeData() function that allows us to to do that.
You may also have bound event listeners to your view chain unbind() with no arguments to remove all previously-attached event handlers from your $el. this.$el.removeData().unbind();
Now you may want to do one of two things here. You may want to remove your view element completely OR you just want to remove any child elements you’ve appended to it during it’s life. The latter would be appropriate if, for example, you’ve set the $el of your view to be some DOM element that should remain after your view behavior is complete
In the former case, this.remove() will obliterate your view element and it’s children from the DOM.
In the later case, this.$el.empty() will remove all child elements.
Check out this fiddle if you want to fool around with my solution.
http://jsfiddle.net/oakley349/caqLx10x/
I want to have a Marionette ItemView (or LayoutView), which rerenders when its model changes. It is actually pretty easy to implement:
modelEvents: {
'change': 'render'
}
However, not every view displays every attribute of the model. So I had an idea to lessen the number of rerenders by listening to only those events, that change some of the attributes. If only one attribute is required by the view, the situation is also easy:
modelEvents: {
'change:attribute': 'render'
}
However, it is more complicated, if several attribute changes need to be listened to. Both
modelEvents: {
'change:attribute1': 'render',
'change:attribute2': 'render'
}
and
modelEvents: {
'change:attribute1 change:attribute2': 'render'
}
would rerender the view twice if both attribute1 and attribute2 are changed in one event. Is there any simple syntax to be notified only once in such an occasion? I know, I can do this:
modelEvents: {
'change': 'checkIfRenderNeeded'
},
checkIfRenderNeeded: function(event) {
if (('attribute1' in event.changed) || ('attribute2' in event.changed)) {
this.render();
}
}
But is there some more elegant solution? Maybe some special syntax to include this behaviour in modelEvents property without having to program a change checker on general change event listener?
The same solution as Paul Rowe, but in the context of Marionette:
you can use Underscore's _.debounce function to wrap your render function:
var lazyRender = _.debounce(render, 50)
and
modelEvents: {
'change:attribute1 change:attribute2': 'lazyRender'
}
Then, if both attribute1 and attribute2 change, even several times, within a 50 milliseconds timespan, lazyRender will be called several times but the render function will only be called once.
I'm not familiar with marionette, but I'll pull a page from my own experience.
Set up a function that serves as a front to render. All attempts to render go through this function. This function manages a timer which, when complete, fires the render function. Whenever the function is called, it clears the timer so there are no queued requests to render. It then resets the timer.
I would like to include multiple mixins within a view in Ember.js and more than one of the mixins and/or the view uses a same event (e.g. willInsertElement). I'm running Ember 1.4.0-beta.5.
I understand that the event in each mixin will be overridden by the view. However, I have read that it is possible to use the same event hook in the mixin and view, or multiple mixins included in the same view, by calling this._super(); at the start of the mixin's aforementioned event method. However, I have not been able to successfully make this happen. My question is, thus, how can I write logic within the same event hook in a view and mixin (or multiple mixins included in the same view) so that all the logic within each occurrence of the event hook will be called.
Here is an example:
App.StatsView = Em.View.extend(
App.DateFormatting, {
willInsertElement: function() {
// Some view-specific logic I want to call here
},
});
App.DateFormatting = Em.Mixin.create({
willInsertElement: function() {
this._super(); // This doesn't work.
// Some mixin logic I want to call here
},
});
N.B. One approach here might be to not use a mixin and extend a view instead (because willInsertElement is specific to Em.View), but that isn't maintainable in our apps.
If the different functions you're using are not dependent on each other, it's the best solution to not override the willInsertElement hook, but to tell the function to be raised when the event/hook gets called.
Like:
App.StatsView = Em.View.extend(App.DateFormatting, {
someSpecificFunction: function () {
console.log('beer me');
}.on('willInsertElement')
});
App.DateFormatting = Em.Mixin.create({
dateFormattingFunction: function () {
console.log('beer you');
}.on('willInsertElement')
});
I would like to know if it possible to extend in some way the mechanism Marionette Layouts are based on creating a sort of stack like navigation.
Marionette behaviour.
Before a region show()'s a view it calls close() on the currently displayed view. close() acts as the view's destructor, unbinding all events, rendering it useless and allowing the garbage collector to dispose of it.
My scenario.
Suppose I have a sort of navigation mechanism where a Layout acts as controller and first displays an ItemView called A, then a click somewhere allows to switch to ItemView B. At this point, an action on B (like for example a tap on a back button) allows to return to A without recreating it.
How is it possible to achieve the previous scenario without creating again A and maintaning its state?
For iOS people, I would like to mimic a sort of UINavigationController.
Any advice?
EDIT
My goal is to restore a prev cached view with its state without creating it again.
My scenario is the following. I have a layout with two regions: A e B.
I do a click somehere within A and A and B are closed to show C and D. Now a back click would restore A and B with their states. Events, models, etc...but since views are closed events are removed.
Use a backbone router to listen to URL change events. Setup routes for each of your views and then have the router call the layout to change the view it's displaying in response to each route. The user could click back or forward any number of times and the app responds accordingly and displays the correct view. Your router might look like:
var Router = Backbone.router.extend({
routes: {
'my/route/itemViewA': 'showItemViewA',
'my/route/itemViewB': 'showItemViewB'
},
showItemViewA: function () {
layout.showItemView('a');
},
showItemViewB: function () {
layout.showItemView('b');
}
});
Your layout might look something like this:
var Layout = Backbone.Marionette.Layout.extend({
regions: {
someRegion: 'my-region-jquery-selector'
},
initialize: function () {
this.createViews();
},
createViews: function () {
this.views = {
a: new Backbone.Marionette.ItemView,
b: new Backbone.Marionette.ItemView
};
},
showItemView: function (view) {
this.someRegion.show(this.views[view]);
// You might want to do some other stuff here
// such as call delegateEvents to keep listening
// to models or collections etc. The current view
// will be closed but it won't be garbage collected
// as it's attached to this layout.
}
});
The method of communication between the router and the layout doesn't have to be a direct call. You could trigger further application-wide events or do anything else you can think of. The router above is very basic but gets the job done. You could create a more intelligent router to use a single route with parameters to determine dynamically which itemView to show.
Every time the user does something that requires changing views, you can update the browser's history by using router.navigate('my/route/itemViewB', {trigger: true});. Also, if you set up your app to only render on history change events then you don't need to set up two mechanisms for rending each view.
I use this pattern in my own apps and it works very well.
#Simon's answer is headed in the correct direction. However, the only way to stop Marionette from closing views is to modify a bit of it's Region code.
var NoCloseRegion = Marionette.Region.extend({
open: function(view) {
// Preserve the currentView's events/elements
if (this.currentView) { this.currentView.$el.detach(); }
// Append the new view's el
this.$el.append(view.el);
}
});
The, when be sure to specify our new Region class when creating the Layout view
var Layout = Backbone.Marionette.Layout.extend({
regions: {
someRegion: {
selector: 'my-region-jquery-selector',
regionType: NoCloseRegion
},
},
initialize: function () {
this.createViews();
},
createViews: function () {
this.views = {
a: new Backbone.Marionette.ItemView,
b: new Backbone.Marionette.ItemView
};
},
showItemView: function (name) {
// Don't `show`, because that'll call `close` on the view
var view = this.views[name];
this.someRegion.open(view)
this.someRegion.attachView(view)
}
});
Now, instead of calling show which closes the old view, renders the new, and attaches it to the region (and triggers a few events), we can detach the old view, attach the new, and open it.
I'm making a Backbone.js app and it includes an index view and several subviews based on id. All of the views have been bound with mousedown and mouseup events. But every time I go from a subview to the index view and then go to any of subviews again, the mousedown and mouseup events in the current subview will be triggered one more time, which means when I click the subview, there will be several consecutive mousedown events triggered followed by several consecutive mouseup events triggered.
After looking through my code, I finally found that it's the router that causes this problem. Part of my code is as follows:
routes: {
"": "index",
"category/:id": "hashcategory"
},
initialize: function(options){
this._categories = new CategoriesCollection();
this._index = new CategoriesView({collection: this._categories});
},
index: function(){
this._categories.fetch();
},
hashcategory: function(id){
this._todos = new TodosCollection();
this._subtodolist = new TodosView({ collection: this._todos,
id: id
});
this._todos.fetch();
}
As you can see, I create the index collection and view in the initialize method of the router, but I create the subview collection and view in the corresponding route function of the router. And I tried to put the index collection and view in the index function and the click event in index view will behave the same way as subviews. So I think that's why the mousedown and mouseup will be triggered several times.
But the problem is, I have to use the id as one of the parameters sent to subview. So I can't create subview in the initialize method. What's more, I've already seen someone else's projects based on Backbone and some of them also create sub collection and view in the corresponding route function, but their app runs perfectly. So I don't know what is the root of my problem. Could someone give me some idea on this?
Sounds like you're having a delegate problem because:
all sub views all use the a same <div> element
Backbone views bind to events using jQuery's delegate on their el. If you have a view using a <div> as its el and then you use that same <div> for another view by replacing the contained HTML, then you'll end up with both views attached to that <div> through two different delegate calls. If you swap views again, you'll have three views receiving events through three delegates.
For example, suppose we have this HTML:
<div id="view-goes-here"></div>
and these views:
var V0 = Backbone.View.extend({
events: { 'click button': 'do_things' },
render: function() { this.$el.html('<button>V0 Button</button>'); return this },
do_things: function() { console.log('V0 clicked') }
});
var V1 = Backbone.View.extend({
events: { 'click button': 'do_things' },
render: function() { this.$el.html('<button>V1 Button</button>'); return this },
do_things: function() { console.log(V1 clicked') }
});
and we switch between them with something like this (where which starts at 0 of course):
which = (which + 1) % 2;
var v = which == 0
? new V0({el: $('#view-goes-here') })
: new V1({el: $('#view-goes-here') });
v.render();
Then you'll have the multi-delegate problem I described above and this behavior seems to match the symptoms you're describing.
Here's a demo to make it easy to see: http://jsfiddle.net/ambiguous/AtvWJ/
A quick and easy way around this problem is to call undelegateEvents on the current view before rendering the new one:
which = (which + 1) % 2;
if(current)
current.undelegateEvents(); // This detaches the `delegate` on #view-goes-here
current = which == 0
? new V0({el: $('#view-goes-here') })
: new V1({el: $('#view-goes-here') });
current.render();
Demo: http://jsfiddle.net/ambiguous/HazzN/
A better approach would be to give each view its own distinct el so that everything (including the delegate bindings) would go away when you replaced the HTML. You might end up with a lot of <div><div>real stuff</div></div> structures but that's not worth worrying about.