I have this code in coffeescript and i can't modify it:
events:
"click #chat-btn": "_toggleChat"
render: ->
compiledTemplate = _.template(sessionNavbarTemplate)
#$el.html compiledTemplate
#_setToggleButtonStatus()
initialize: ->
#$parentEl = null
_setToggleButtonsStatus: ->
$("#chat-btn", #$el).toggleClass "active", #$parentEl.hasClass("chat-on")
I try to insert the last line of code in the initialize section but the program crash.
I have an interface where if i click a button i have the chat. I don't know coffeescript very well and i would the chat appear without pressing the button. How can i do?
This part of the view:
events:
"click #chat-btn": "_toggleChat"
essentially binds a click handler to #chat-btn; the binding is actually done through event delegation but that's not important here. If you want to simulate someone clicking on #chat-btn then just call click on it:
$('#chat-btn').click()
Demo: http://jsfiddle.net/ambiguous/pX6QZ/
Keep in mind that #chat-btn won't necessarily be in the DOM until after that view has rendered.
Related
I suspect that the way I am handling views in backbone.js is flawed in such a way that it is creating a "memory leak".
There is a view that is constantly being overwritten with another copy of itself. The new copy is linked to a different model.
I am creating and adding the view to it's parent view by setting the el option when creating the child view.
The strange thing that is happening is that even though a new view is being rendered over top of the old view, when I click the "button" an alert pops up for every childView that was every rendered, even though the button they were listening to should be gone, they respond to the new button.
I've implemented a quick fix by calling a function on the old view to stop listening to events before the new view is added. But that this problem exists at all tells me that all of the old views are hanging around and will slow the application over time if the user does not refresh the page often enough.
var parent = new (Backbone.Marionette.ItemView.extend({
ui:{
child_container: '#child-container'
},
onRender: function(){
// Listen to outside event
...
}
on_Outside_Event: function(new_model){
// Quick fix prevents multiple alerts popping up for every child view when "button" is pressed
this.child_view.destroy_view();
// New child view is created and rendered on top of the one that was there before
this.child_view = childView({
el: this.ui.child_container, // <-- Is this the problem?
model: new_model
})
this.child_view.render();
}
}))();
var childView = Backbone.Marionette.ItemView.extend({
events:{
'click button': 'on_click_button'
},
on_click_button: function(){
// Alert pops up once for every view that was ever displayed.
alert('Button clicked');
},
// QUICK FIX
destroy_view: function(){
this.undelegateEvents();
}
})
In case this is helpful, here is a screen shot of the actual application. A calendar of appointments is on the right. The problem child view - a view of the individual appointment that the user wants to see is on the left.
When I click the "Cancel appointment" button, that function gets called for every appointment that was every displayed in that area, even though I am listening to the event using: events:{ 'click #cancel-button': 'on_button_click'}
None of the other buttons, interactions, and other controls have this same issue, I assume because all the others actually live views that are children of the child appointment view and not in the child appointment view itself
A possible fix?
Did a little searching around, does this fix look adequate?
Normally, I think the removeData().unbind(); and remove() functions are called directly on this.$el, but this did not work here, I think because I added the child view using the el option when it was created (el: this.ui.child_container)
var childView = Backbone.Marionette.ItemView.extend({
...
// REAL FIX
destroy_view: function(){
this.undelegateEvents();
this.$el.children().removeData().unbind();
this.$el.children().remove();
}
I think you should make your parent view a LayoutView (that's just an ItemView with added functionality to handle regions iirc), have a region defined for where you want this child view to appear, and then do:
Parent = Backbone.Marionette.LayoutView.extend
regions:
child: "#child-container"
on_Outside_Event: ->
childView = new ChildView(...)
#getRegion("child").show(childView)
(sorry I used coffeescript, it's faster to write, but you can translate easily).
Marionette will handle everything: closing your old child view, unbinding events, etc.
I've binded window's scroll event to a view's method like:
MyView = Backbone.View.extend({
initialize: function(){
_.bindAll(this, 'handleScrolling');
$(window).off('scroll', this.handleScrolling).on('scroll', this.handleScrolling);
}
})
I see this is not working. If this callback is triggered as many times as this view is instantiated. However, if I remove handler from off, then it is correctly unbinding and triggers only once per scrolling. Like:
$(window).off('scroll').on('scroll', this.handleScrolling);
Any idea why this is happening? I dont want to remove all callbacks from this event as other views/codes may bind event to it which will make app behaving unexpected.
Is there any better way of binding events to window/document or other element outside the scope of current view?
Your problem is right here:
_.bindAll(this, 'handleScrolling');
That's equivalent to:
this.handleScrolling = _.bind(this.handleScrolling, this);
so each time you instantiate your view, you're working with a brand new function in this.handleScrolling. Then you do this:
$(window).off('scroll', this.handleScrolling)
But that won't do anything since the this.handleScrolling function that you attached with on:
.on('scroll', this.handleScrolling);
isn't the same function as the this.handleScrolling function that you're trying to .off. The result is that each time you create a new instance of your view, you're leaving the old scroll handler in place and adding a new one.
The proper solution (IMO) is to add a remove method to properly clean things up:
remove: function() {
$(window).off('scroll', this.handleScrolling);
return Backbone.View.prototype.remove.apply(this);
}
and then call view.remove() before creating the new view.
It looks like you have a new instance of the handler this.handleScrolling in each call.
so when jQuery tries to remove the specific handler it will not find the handler in the event registry, so it will not be able to remove it.
Problem: Demo
I would suggest using event namespaces here
$(window).off('scroll.myview').on('scroll.myview', this.handleScrolling);
Demo: Fiddle
Another solution is to use a shared handler like this
What I want to achieve is that on form changes, the whole view should be re-rendered. This is to provide a preview of the data just edited, and to hide certain elements in the form when check boxes are ticked.
When the user edits the field and clicks on the button without leaving the filed first two events are fired at the same time: change, click. The change handler first updates the model, which triggers a re-render of the form. When it's the click events turn, nothing happens. I guess it has to do with the re-render because when I comment out the
#model.on 'change', #render, #
Both event handlers are executed as it should be.
Maybe the click handler is not executed because the click target has been removed from dom and a new button has been added? How would I fix this? I was thinking the code I wrote was 'idiomatic' Backbone.js, but I'm still learning :-)
Here is a simplified version of my code showing the problem:
jsbin
Let us add a few things so that we can see what's going on. First we'll mark the Save button with a unique ID:
render: ->
id = "b#{Math.floor(Math.random() * 1000)}"
console.log('button id = ', id)
#...
And then we can see which button was hit:
save: ->
console.log('pressed = ', #$('button').attr('id'))
#...
We'll also add a global click handler to watch the <button> outside of the Backbone stuff:
$(document).on('click', 'button', ->
console.log('global click = ', #id)
)
Live version: http://jsbin.com/oviruz/6/edit
Play around with that version a bit and you might see what is going on:
Change the content of the <input>.
Try to click Save.
As soon as the <input> loses focus, the change event is triggered.
That event calls fieldChanged which does #model.set(...).
The #model.set call triggers Backbone's events, in particular, the #model.on(...) from the view's initialize.
The Backbone event sends us into render which does a #$el.html(...) which replaces both the <input> and the <button>.
The html call kills all the DOM elements inside the view's el. But, and this is a big but, the browser needs to get control again before this process finishes.
Now we're back into the event queue to deal with the click on Save. But the <button> we're clicking is a zombie as the browser's work queue looks like this: deal with the click event, replace the DOM elements from 3.4. Here the work from 3.4 isn't complete so the <button> that you're clicking is half in the DOM and half dead and won't respond to any events.
You have two event queues fighting each other; your Backbone events are changing the DOM behind the browser's back and, since JavaScript is single threaded, the browser is losing and getting confused.
If you delay the #$el.html call long enough to let the browser catch up:
set_html = =>
#$el.html """
<input type="text" id="text" value="#{#model.get('foo')}"/>
<button class="save" id="#{id}">Save</button>
"""
setTimeout(set_html, 1000) # Go higher if necessary.
You'll get the behavior you're expecting. But that's an awful, horrific, nasty, and shameful kludge.
Messing around with the DOM while you're still processing events on those DOM elements is fraught with danger and is little more than a complicated way to hurt yourself.
If you want to validate the field when it changes and bind the view's render to "change" events on the model, then I think you'll have to do the validation by hand and use a silent set call:
fieldChanged: (e) ->
field = #$(e.currentTarget)
#model.set({ foo: field.val() }, { silent: true })
// #model.validate(#model.attributes) and do something with the return value
If you do a #model.save() in the Save button's callback, the silent changes will be validated en mass and sent to the server. Something like this: http://jsbin.com/oviruz/7/edit
Or you skip the #model.set inside fieldChanged and just use #model.validate:
fieldChanged: (e) ->
val = #$(e.currentTarget).val()
// #model.validate(foo: val) and do something with the return value
and leave all the setting stuff for save:
save: ->
#model.save(foo: #$('#text').val())
Something like this: http://jsbin.com/oviruz/8/edit
You can add a little delay before update model in fieldChange, you can replace change event with keyup. There might be many workarounds, but probably best was would be not to re-render whole view on model change.
I have a View called Form that renders either a form to edit a list, or the list itself, depending on what argument is passed to render. I've added event handlers so that the show/edit mode can be toggled. I've taken this out from the code below to keep it simple, but this just gives a bit of context to what the View does in context.
I can instantiate this Form view as a child in another view that requires a form, or the list to be rendered, which I've done in the New view, where it would be rendered as a form.
When I need to save, I call the form:save event, which triggers a routine in the Form view that saves the form, I've just made it call a console.log here to show it works. In my code, I call form:save through an $('a#submit').click binding which binds to navigation buttons that are inserted by an ApplicationView (but I don't think that matters for the purposes of this question.)
Lets say I navigate away from the New view, and I go back to it a number of times. When I hit save, the method runs the number of times I have instantiated and rendered a new Form view.
So far:
I've tried doing unbind() and remove() in a close method on the Form view from the New view with no luck.
I think I may have problems with scoping, but I'm unsure.
I know this isn't related to my navigation bindings.
I think this may be to do with zombie views.
Any pointers to make it only run once?
App.Views.New = Support.CompositeView.extend
initialize: (options) ->
_.bindAll this, 'render'
#model = new App.Models.Item()
render: ->
self = this
form = new App.Views.Form model: #model, collection: #collection
#$el.append form.render().el
setTimeout (->
$('a#submit').click (e) ->
e.preventDefault()
App.eventHandler.trigger 'form:save'
), 0
this
App.Views.Form = Support.CompositeView.extend
initialize: ->
_.bindAll this, 'render', 'save'
App.eventHandler.on 'form:save', #save
render: ->
self = this
# RENDER TEMPLATE HERE
this
save: ->
console.log 'form saved'
I believe your issue is that you are creating a new view each time you want to render the form, but you aren't getting rid of your old view. What you can do is either destroy your old view, or keep a reference to it and instead of creating a new view each time, just pass in the model to the existing view and refresh/rerender the display
I'm trying to implement view tests for a Coffeescript implementation of the ubiquitous backbone.js 'todo' example (see github.com/rsim/backbone_coffeescript_demo.)
My jasmine tests of the above demo work pretty well, except for view events. I expect I am stuck on one or both of the following i) I do not understand the event binding in the view code, ii) I do not understand how to properly set up the Jasmine test of the view code events.
Here is an example of the 'edit' event...
class TodoApp.TodoView extends Backbone.View
tagName: "li"
template: TodoApp.template '#item-template'
events:
"dblclick div.todo-content" : "edit"
...
initialize: ->
_.bindAll this, 'render', 'close'
#model.bind 'change', #render
#model.bind 'destroy', => #remove()
render: ->
$(#el).html #template #model.toJSON()
#setContent()
this
edit: ->
$(#el).addClass "editing"
#input.focus()
...
...now here's a test of whether focus was gained upon double clicking:
describe "edit state", ->
li = null
beforeEach ->
setFixtures('<ul id="todo-list"></ul>')
model = new Backbone.Model id: 1, content: todoValue, done: false
view = new TodoApp.TodoView model: model, template: readFixtures("_item_template.html")
$("ul#todo-list").append(view.render().el)
li = $('ul#todo-list li:first')
target = li.find('div.todo-content')
expect(target).toExist()
target.trigger('dblclick') # here's the event!
it "input takes focus", ->
expect(li.find('.todo-input').is(':focus')).toBe(true)
The expectation on neither i) the spy nor ii) the focus is met.
Is there a peculiarity to testing backbone.js event code about which I should be aware in Jasmine?
you're spying on the view's edit method. this replaces the method with a spy object, which means the actual edit method won't get called. therefore, you're #input.focus will never fire.
since you want the test to actually call your edit method, i would remove the spy for it.
side note: don't call expect methods in your beforeEach. if you truly need to set an expectation on those, create an it block for them.
I'm not great with coffescript so I might be missing something but where are you setting up your spy?
In order to test event calling you may need to refresh the view's events once you've set up the spy.
spyOn(view, 'edit');
view.delegateEvents();
target.trigger('dblclick');
it("should call edit when target is double clicked", function() {
expect(view.edit).toHaveBeenCalled()
});
The issue with this is that Backbone.View events object is using event delegation. For the events to be able to be called work the element has to be part of DOM, you can do this by doing something like $('body').append(someView.el) in your beforeEach. Personally, I try not to test if Backbone is correctly setting the events and triggering clicks manually, is more practical for unit tests to call the callback handlers directly avoiding the DOM completely which can slow down your tests a lot.
For :focus is the same problem, there has to be an element in the DOM so that jQuery can tell if an element is focused. In this case it's better to set some state as part of your component and not checking for state via querying the DOM, e.g.: someView.hasFocus === true. Alternatively you can spy on the elements focus implementation and check if it was called.
I did not write my test in coffeescript, but I did have the same problem, so I hope you will forgive me for answering in javadcript. I ended up breaking down your test into two different tests. First, I tested if calling the view's edit function set the focus on the input box. After that, I tested whether the edit was called when the label was double-clicked, and have not yet gotten that test to pass. But here's how I tested if the edit function worked.
describe ("A todo item view", function() {
var my_model;
var todo_view;
beforeEach(function() {
my_model = new Todo({content:"todo value", done:false});
todo_view = new TodoView({model:my_model});
});
it("should set the focus on the input box when the edit function is called", function(){
$('body').append( todo_view.$el ); //append the view to Specrunner.html
todo_view.edit(); //call the view's edit function
var focus= document.activeElement; //finds what element on the page has focus
expect(focus).toBe('.todo-input'); //jasmine-jquery matcher checks if focused element has the .todo-input class
});
Something that might be causing problems is that your model And your view are declared inside beforeEach. Declaring them inside beforeEach means they only exist inside beforeEach's scope, and no longer exist when you run your it.
Also, does setFixtures do what you think it does? The focus cannot be set on an element that is not part of the DOM tree, so I appended the view's el to the body of the jasmine spec itself. (I'm using the HTML specrunner, not the command-line version) That makes it part of the dom tree and therefore allows it to have focus, and also makes whether it has focus testable.