Mixing Google Maps custom overlays with Backbone Views

Question

TL;DR

Is PinView.prototype = _.extend(PinView.prototype, google.maps.OverlayView.prototype) the \"proper\" way to have a Backbone View

Answer 1

Nice idea! I'm usually a bit sceptical about weather or not you're 'correct' when things work so if you haven't run into a showstopper and the overlays shows up and does what the're supposed to do I'd say you are.

One thing to check out closer, though:

This isn't (and can't) be "real" multiple inheritance - that concept isn't really relevant in a prototype based language: one implementation of a method will inevitable "win" and overwrite the other implementation, at least when using _.extend()

This means that if there are members or methods with the same names in Backbone.View and google.maps.OverlayView the one last in your _.extend() call will be the one that takes over. But when I inspect them using Chrome's Developer Tools I didn't see any obvious collision of this kind.

So my recommendation: continue using this, just test a lot. I'd love to see an example of this technique some time.

Answer 2

Ah! So I've been doing the above, but it's never felt right.

Then I found this discussion on a Backbone group which leads me to the following:

var MyView = (function(){
    var view = function(){
        Backbone.View.apply(this, arguments);
    };

    view.extend = Backbone.View.extend;

    _.extend(view.prototype, Backbone.View.prototype, google.maps.OverlayView.prototype, [other prototypes...], { [VIEW DEFINITION] });

    return view;
}());

This way if we need to override any of the definitions in a class we're extending from, we can since it's earlier in the _.extend chain (later definitions overwrite earlier definitions).

I'm working on 'extending' extend to keep track of the "parent" object's references that would be overridden and providing a method to call them still (like Python's super call). I haven't decided if this should be done through monkey-patching, an intercepter pattern (via underscore's _.tap() method or something else, but I think it'll add a lot of flexibility.

This would allow you to define an initialize view in your "parent" class which could be called by doing something like _.super('ParentClass', 'initialize'); at the end of the "child" class's initialize routine...