listenTo change in behavior, 1.2.0?

[bazineta]

Using the 1.1.2 release, listenTo() was able to listen for events from objects that provide the typical on() interface; in our case, an Ace editor session, which emits 'change' events, e.g., EditSession.on('change', function (e)). Under 1.1.2, we've used listenTo() to listen for these events from the editor session.

Using the 1.2.0 release, listenTo() does not appear to be able to listen for these events; they're emitted, and the editor session is present in the View's _listeningTo, but the callback is no longer fired.

We were using listenTo() for automatic cleanup of the listener function. Curious if this was never supposed to work in this manner, or if it's a bug. The changes to listening in 1.2.0 are quite extensive, so it's a bit difficult to see what might be the key difference for one unfamiliar with them.

[akre54]

Mind writing up a small test case so we can take a look? I'd be interested to see what your code looks like.

[jridgewell]

// Test Case
var events = {};
var obj = {
  // Any non Backbone.Events event implementation will work...
  on(name, callback) {
    events[name] = callback;
  },
  off(name) {
    events[name] = null;
  }
};

var view = new Backbone.View();
view.listenTo(obj, 'test', console.log);
view.stopListening();

This is a side-effect of fixing #3455 (comment). Since now both the listener and the listenee should be able to clean up memory in the other object, I had to share private state between the two objects. internalOn is used so that this private data is never leaked outside of Backbone. But it also means that #listenTo uses only internal Backbone code instead of the public #on.

I'm able to fix this by sharing the state privately inside Backbone instead of through a private function. I'll have to look into the performance impact.

[akre54]

Ah. I'd say it's not in our contract to support other events systems, but if we can make it work we probably should. Is there any way other than a singleton event @jridgewell? This seems pretty hacky and brittle.

[jridgewell]

Reverting #3594 should also do the trick, since the listener will keep track of the events.

[akre54]

What did #3455 and #3594 get us? Kind of hard to follow those discussions.

[jashkenas]

Since, #3594 is your baby, @jridgewell — go ahead and revert it if you think that it's reasonable and the appropriate fix.

[jridgewell]

#3455 fixed a pretty severe memory leak:

obj.on('event', function() {});
obj2.listenTo(obj, 'event', function() {});

obj2.stopListening();
// obj2 still holds a reference to obj

It also allowed the listenee can clean up references:

obj2.listenTo(obj, 'event', function() {});

obj.off();
// obj2 still holds a reference to obj

#3594 cleaned up the implementation, but I wasn't taking library interop into account. Hence, the internalOn function, instead of using the public #on.

---

Let me get test cases setup, and I'll revert once I know it'll fix the library interop.

[jridgewell]

Oh man, even if we revert #3594, the previous implementation used a private internalStopListening() that doesn't call the public #off. Reverting won't fix.

I'll look into what we can do to resolve this, but it's not going to be a pretty solution.

[jashkenas]

Point of clarification — the current approach is fine, except that you can't .on( to an event from a different events library? Yes?

[jridgewell]

the current approach is fine, except that you can't .on( to an event from a different events library? Yes?

Exactly.

[jashkenas]

Then let's leave the current approach as it stands.

@bazineta Is it not a viable approach for your Ace editor session object to mixin Backbone.Events ?

[bazineta]

A number of viable approaches exist; that's one of them. Agree, FWIW, that there don't seem to be good paths forward from here with respect to changing the current behavior, so I'd instead recommend documenting it as a warning, i.e., this would have worked before, does not now, will fail silently, and should be addressed via other means.

[gaperton]

@jashkenas "Point of clarification — the current approach is fine, except that you can't .on( to an event from a different events library? Yes?"

No. Message maps are broken. In this code triggering a, b, or c won't fire event handler.

this.listenTo( this, {
      'hello' : function(){
           this.hello = true;
      },

      'a b c' : function(){
          this.abc = true;
       }
});

[stevewillard]

Having a similar problem to @gaperton with Backbone 1.2.1 and Marionette 2.4.2. The modelEvents mapping object doesn't seem to trigger "change" "sync" or other callbacks. When I revert back to Backbone 1.1.2, everything works.