Should removeAttr replace model instance with an instance?

1

When the model gets a new set of data for an instance already in the model store, can.Model checks removeAttr to see if it should replace or “merge” the current instance with the new data.

So, when removeAttr is set to true, can.Model will strip out computes from the model instance. can.Model replaces the current instance with the new data. The new data is not yet an instance of the model so it will not have the computes added on by the define plugin.

can.Model.extend({
  removeAttr: true,
  findOne: 'GET /todo/{id}'
},{
  define: {
    // This compute is not supplied by the response
    // so it will be stripped in this case.
    someCompute: {
      get: function () {
        return 'Hello World';
      }
    }
  }
});

I’ve heard before that we shouldn’t have computes in our model instances. They are not that common but are sometimes needed when the service layer response is a little… not nice.

It seems like can.Model should process the define object before merging the attributes but perhaps there’s a better way of handling this situation in the model?

Part of can.Model I am referring to: https://github.com/canjs/canjs/blob/master/model/model.js#L234

2

Can you describe what you mean a bit better? Especially regarding “computes from the model instance”. Can you provide an example of a compute on the model instance?

The define getter you show shouldn’t be stripped out by model.

3

Re-reading, your example is not showing a compute on a model instance, it’s a define getter which are totally fine and encouraged to be put on models.

I really don’t think the stripping you are suggesting is likely happening.

Define getters aren’t serialized, and I am assuming only physical properties would be removed. I’m not even sure how mechanically a compute would be removed from an instance.

Can you show this behavior in a jsbin?