model method without prototype on Backbone.Collection causes crash

[johnfn]

This was discussed previously in #2080; however it was discussed in the context of _.bindAll(this) and I think that confused the discussion, because the issue is not about _.bindAll(this) at all. It actually happens whenever the model function lacks a prototype property. For example:

var myCollection = Backbone.Collection.extend({ 
    initialize: function() { 
        this.model.prototype = null;
    }, 

    model: function(attrs, options) { 
        return new Backbone.Model(attrs, options); 
    }
});

new myCollection([{ a: 1 }]); 

Backbone errors on this line https://github.com/jashkenas/backbone/blob/master/backbone.js#L939 because prototype doesn't exist.

Obviously, few people would write this.model.prototype = null, but a lot of people might write this.model = _.bind(this.model), which also removes the prototype. Backbone should be able to handle this case.

It seems like it'd be pretty straightforward to have line 939 also check for the existence of prototype. What do you think?

[jamiebuilds]

I think the bigger issue here is that when model is a function that returns an instance modelId will not do what it is meant to. This could be fixed by making modelId:

modelId: function(model, attrs) {
  return attrs[model.idAttribute || 'id'];
}

Since all the uses of it have a reference to model handy and since it's not released it would be easy to make this change.

[jamiebuilds]

Actually the only issue would be with the collection.get() method.

[jridgewell]

I was always a little curious why #modelId didn't receive a model instance. That might be a handy PR.

As for setting model.prototype = null, I don't think supporting it is really necessary. Functions have a prototype property, and it is an object. Anything else doesn't seem like good JavaScript.

[johnfn]

@jridgewell _.bind and _.bindAll return functions without a prototype property, and I'm sure there are other functions that do the same thing. Saying "Anything else doesn't seem like good JavaScript" flies in the face of underscore.js as a library.

[jamiebuilds]

@johnfn But why are you trying to bind the model function anyways?

[johnfn]

@thejameskyle I wanted to use a property on this that I set inside initialize.

[jamiebuilds]

Hmm, does it make sense to potentially change the constructor in _prepareModel to:

var model;
if (this._isModel(this.model.prototype) || this.model === Model) {
  model = new this.model(attrs, options);
} else {
  model = this.model(attrs, options);
}

This way it doesn't new functions that return model instances, and you have the correct this.

[jridgewell]

Obviously, few people would write this.model.prototype = null, but a lot of people might write this.model = _.bind(this.model), which also removes the prototype. Backbone should be able to handle this case.

I read the code and jumped into the discussion. Sorry, I should have finished reading.

Changing #modelId wouldn't be the worse thing?

function modelId(attrs) {
    return _.result(this.model.prototype, 'idAttribute', 'id');
}

[jamiebuilds]

function modelId(attrs) {
    return _.result(this.model.prototype, 'idAttribute', 'id');
}

@jridgewell I don't see how that helps?

[jridgewell]

If this.model.prototype == null, _.result will guard against a null obj and return the default. Though now that I think about it, default is only on edge.

[jamiebuilds]

That means it'd still be a problem if you have a custom idAttribute with a bound model method or a function that returns a model instance.

[jridgewell]

That was deemed acceptable in #2836. I was just trying to get rid of the error in the base #modelId.

I think it's going to end up being left to you to define a custom #modelId if you're not going to provide a true constructor function. It's a hell of a lot better than setting bound.prototype = {idAttribute: 'id'}; before #modelId landed.

[jamiebuilds]

Since modelId has not been released, there is the potential to pass it the model modelId(model, attrs) and handle this use case better. Although, I'm not sure how to handle the get use case other than storing a reference to the various idAttribute's in the container and looking for each of them.

[jridgewell]

I realize now I forgot the attrs[] access in my #modelId...

function modelId(attrs) {
    return attrs[_.result(this.model.prototype, 'idAttribute', 'id')];
}

Also, after thinking about it, it does make sense that #modelId only takes the model's attributes since the id should really only be dependent on the attributes ("{attrs.id}", "{attrs.type}-{attrs.id}", etc). There may be some places where using this.modelId(model.attributes) is unnecessary, though, since model.id should always be up to date?

[jamiebuilds]

@jridgewell That's essentially what exists today, this update was so that Collections could determine uniqueness (ids) instead of models (See: 4e2d209).