this was a very naive implementation, meant to be an illustration of an idea, and not really production ready code.

regarding the need to access the target object from the mixin – yeah, this has been the largest problem i’ve encountered in trying out these ideas in real code. i have some ideas for getting around that, but it all involves more code than i like.

i think there’s value in this idea, still. but it will need to be fleshed out in to something that is easy to use and provides real value without a lot of overhead.

Interesting post, thanks. It seems like the approach here is to only mix in public methods, and if there is internal state that needs to be maintained, that they not be maintained on the target class. Seems like a good idea, so that you can avoid conflicts on the target class. Although doing this by manipulating the function’s context does prevent your mixin functions from using other functionality on the target class, although maybe this is intentional?

And if I’m reading it correctly, your first implementation here would pollute the source mixin object:

//Dummy mixin implementation

var CoolMixin = {

bindTo: function(args) {

this._bindings || (this._bindings = []);

this._bindings.push(args);

},

getBindings: function() {

return this._bindings;

}

};

var A = new Backbone.View({});

var B = new Backbone.View({});

mixInto(A, CoolMixin, ‘bindTo’, ‘getBindings’);

mixInto(B, CoolMixin, ‘bindTo’, ‘getBindings’);

//Now let’s bind A and B to events on C

var C = new Backbone.Model({});

//This has the effect of applying CoolMixin#bindTo in the context of CoolMixin, thus adding a _bindings property to CoolMixin.

A.bindTo(C, ‘change’, A.render);

//And since the CoolMixin methods on B are also bound to the same source, B now has A’s bindings.

console.log(B.getBindings());

//And if we bind B to another event, A gets them as well

B.bindTo(C, ‘change’, B.render);

console.log(A.getBindings());

And I believe the second implementation of mixInto is missing a return statement near the end and should read:

return source[method].apply(source, args);

If you’re trying to avoid maintaining state on the target object, you lose the simplicity of the object literal literally getting mixed in. At that point you may as well just make another standalone object to track the mixin’s state. This is something we’ve done in similar circumstances when there’s a lot of state to track, and I think is similar to your approach with the EventBinder, except it explicitly passes the state object instead of passing it through the function context. With this approach, you have a plain object literal mixin that mixes in some sort of initialization method onto the target class, and that initialization method creates a separate object to manage any state that the mixin needs to maintain, as well as mixes in any additional functionality. This approach also lets you be really careful (if you want to be) and even add a check at runtime for whether the mixin would overwrite an existing method. Like this:

//Utility function for getting all properties on an object, including ones set on its prototype chain

var allKeys = function(obj) {

var keys = [];

for (var prop in obj) { keys.push(prop); }

return keys;

};

//Dummy mixin implementation

var CoolMixinLazy = {

initCoolMixin: function() {

//Mixin state gets closed over here

//You can imagine this using a whole other object rather than just an array if needed.

var bindings = [];

var methods = {

bindTo: function(args) {

bindings.push(args);

},

getBindings: function() {

return bindings;

}

};

//Optional run time check for collisions, or possibly chaining

//methods together (e.g., Backbone.Model#validate)

var collisions = _.intersect(_.keys(methods), allKeys(this));

console.log(_.keys(methods), _.keys(this), collisions);

if (!_.isEmpty(collisions)) throw new Error(‘collision trying to mix in: ‘ + collisions.join(‘, ‘));

//Mix in and return this for chaining

_.extend(this, methods);

return this;

}

};

var LazyView = Backbone.View.extend(CoolMixinLazy);

var D = new LazyView({});

D.initCoolMixin();

//detecting collisions

var DifferentView = Backbone.View.extend({ getBindings: ‘there are none!’ });

var LazyDifferentView = DifferentView.extend(CoolMixinLazy);

var E = new LazyDifferentView({});

E.initCoolMixin();

Personally, almost all of this is overkill for me, which is why I mostly keep using the object literal approach and storing any object state on the target object, just with weirder names than _bindings. Maybe not the best long term strategy, but seems the simplest to me for the moment. :)

-Kevin

If you pluck a function from another object and maintain it’s original context, you’re just creating an alias. Not terribly useful, it’s just syntax suger.

The interesting thing is usually to pluck a function from an object, and bind it to another.

For example, (and this is specifically the use-case you discourage) a jQuery callback.
How do do imagine Backbone’s declarative events get bound to the view?

$(this.el).on(‘click’, ‘.delete’, _.bind(this, someObject,clickhandler));

so clickHander can call this.model.delete(), for example.

Have you even read the source of underscore’s bind method? It’s like 10 lines. Not complicated at all.

No offense, but this article is spreading some serious mis-information. I feel should warn those unfamiliar with the subject to do make sure they get their facts straight.

You could expose the methods you want to mix into the target through the facade and keep the things you don’t want to mix in private.

That way the component is in control of which methods get mixed in, rather then requiring a developer to manage this manually.

http://ericleads.com/2012/08/introducing-applitude-simple-module-management/