बैकबोन 0.9.9: श्रोताओं के बीच अंतर और

Question

मैं बैकबोन 0.9.9 में किए गए नए बदलावों को सीखने की कोशिश कर रहा हूं।

listenTo

var View = Backbone.View.extend({ 

    tagName: "div", 

    intialize: function() { 
     this.listenTo(this.model, 'change', this.render); 
    }, 

    render: function() { 
     this.$el.empty(); 
     this.$el.append('<p>hello world</p>'); 
    } 

}); 

var View = Backbone.View.extend({ 

    tagName: "div", 

    intialize: function() { 
     this.model.on('change', this.render, this); 
    }, 

    render: function() { 
     this.$el.empty(); 
     this.$el.append('<p>hello world</p>'); 
    } 

}); 

पर मैंने सुना है कि listenTo वाई अनुमति देता है:

वर्तमान में मैं listenTo और on के बीच अंतर को समझने के लिए समस्याओं मिला वें stopListening सभी घटनाओं से सदस्यता समाप्त करने के लिए जब उदाहरण के लिए मेमोरी लीक से बचने के लिए दृश्य हटा दिया जाता है।

क्या यह एकमात्र कारण है?

Answer 1

listenTo और stopListening मूल रूप से समुदाय से आया था। वे घटनाओं को बांधना और बाध्य करना आसान बनाने में मदद करते हैं।

इस विषय पर लिखे गए सामान सहित कई सारे मौजूदा दस्तावेज और ब्लॉग पोस्ट इस विचार के आस-पास हैं।

जॉनी ओशिका पहला व्यक्ति है जिसे मैंने इस तकनीक का उपयोग करके देखा था। यह मूल रूप से एक StackOverflow सवाल यहाँ के जवाब के रूप पोस्ट किया गया: Backbone.js : repopulate or recreate the view?

आप पढ़ सकते हैं कि मैं क्या इस बारे में लिखा है, यहाँ:

• Backbone.EventBinder: Better Event Management For Your Backbone Apps
• Zombies! RUN! (Managing Page Transitions In Backbone Apps)
• Backbone.js And JavaScript Garbage Collection

Answer 2

जब आप कोई दृश्य बनाते हैं, तो listenTo और on दोनों ईवेंट जोड़ें हैंडलिंग। हालांकि, जब दृश्य नष्ट हो जाता है, listenTo कॉल automatically remove the event handler होगा। यह prevents memory leaks और ज़ोंबी घटना श्रोताओं।

तो, यदि आप हैंडलर को स्वयं प्रबंधित करना चाहते हैं तो on का उपयोग करें। बस off पर कॉल करना सुनिश्चित करें। अन्यथा, listenTo पर कॉल करें।