Add a "replace" option to Backbone.Model.set

[thesmart]

I needed to update some of a Model's data that came in from the server. Currently, there are two options: call Model.set, or set Model.attributes directly. I didn't want changes to be recorded, but I also couldn't use silent because I needed the respective views to update. So, I wrote a monkey patch:

Backbone.Model.prototype.reset = (attributes, options) ->
    attrs = attributes || {};
    if options.parse
      attrs = this.parse(attrs, options) || {}

    @set(attrs, options);
    @changed = {};

Wondered why Backbone.Model doesn't have a reset method like Backbone.Collection?

[jashkenas]

Reset is an escape hatch, that allows you to easily do efficient rendering in bulk when you know that you need it.

For your case, just use set.

[thesmart]

Can you set without making attribute changes dirty?

On Aug 1, 2014, at 7:28 AM, Jeremy Ashkenas notifications@github.com wrote:

Reset is an escape hatch, that allows you to easily do efficient rendering in bulk when you know that you need it.

For your case, just use set.

—
Reply to this email directly or view it on GitHub.

[gabriellupu]

Calling Model.clear() before Model.set({}) will work in your case? This way you won't extend the current attributes, instead they will be replaced. Model.clear() also supports silent option if you don't want to trigger two "change" events on the model.

[lennerd]

I agree that this method is missing. I also thought about using model.clear() and model.set() in conjunction. Then I ran across the problem, that I trigger the change event twice now.
Using the silent option when calling model.clear() is not an option, because I also want to have a change event fired, when a property gets unset.

A model.reset() method would take a new attributes hash and fill this hash with undefined values for old attributes keys not being present in the new attribute hash.

Model.prototype.reset = function(attrs, options) {
    for (var key in this.attributes) {
        if (key in attrs) continue;
        attrs[key] = void 0;
    }

    return this.set(attrs, options);
};

[TheIronDev]

@lennerd

What about:

Model.prototype.reset = function(attrs, options) {
    for (var key in this.attributes) {
        this.unset(key, {silent:true});
    }
    return this.set(attrs, options);
};

[lennerd]

No, this does not help. Imagine you a have a key foo in the current attributes hash of the model, which is not present in the new attrs hash you pass to model.reset(). When I listen to the change:foo event, it won't be triggered with the new value undefined, because we used model.unset() in silent mode.

Backbone.Model.prototype.reset = function(attrs, options) {
    for (var key in this.attributes) {
        this.unset(key, {silent:true});
    }
    return this.set(attrs, options);
};

var bar = new Backbone.Model();

bar.on('change', function(model) {
    console.log('The model bar has been changed.');
});

bar.on('change:foo', function(model, foo) {
    console.log('Foo has been changed to: ' + foo);
});

bar.set(foo, 'test');
// => The model bar has been changed.
// => Foo has been changed to: test

bar.reset({ foo2: 'test2' });
// => The model bar has been changed.
// Foo was resetted but no change event has been triggered.

http://jsfiddle.net/lennerd/3s1Ltwgu/

[TheIronDev]

Cool, I get what you mean. I'd probably opt for using this.unset(key, options) over overriding this.attributes explicitly, but that's just a matter of swapping out attrs[key] = void 0; 🐼

[tyler-eon]

Pardon any ignorance I show, as I'm still relatively new to backbone.js, but the behavior being discussed sounds like Model.fetch. The description says:

Resets the model's state from the server

It looks as though change events are still triggered but do not make the model "dirty". Is there a reason this approach cannot be taken when you are looking to reset attributes based on a server response? I would imagine the only such situation this might occur is when a model changes as a side-effect of another operation, but generally such side-effects are considered poor programming and should be avoided if possible. If the side-effect cannot be avoided, perhaps it makes more sense to send down an "update model XYZ" response flag instead of the new model attributes and trigger a fetch whenever you see such a response.

Again, pardon any ignorance I am exhibiting in this comment.

[jponc]

@kolorahl ,

What the OP wants to achieve is to clear the current model attributes and pass a new JSON which becomes the new attributes of the model. In this manner, we don't really want to hit the backend if already have the JSON.

[jponc]

I somehow agree with @lupugabriel1 with his clear + set method. But I think this is one functionality that needs to be considered. Something like Backbone.Collection#reset

[thesmart]

The reason I needed this is because the world is changing. Backbone assumes Model#fetch() XHR is the primary method for loading data from the server, but we're doing a lot more stuff using websockets. When data gets pushed to the client, it's redundant to call .fetch and we need a decent way to side-load the data and still get an event hook to trigger.

[jridgewell]

Why aren't you using #set?