Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Collection#fetch updates existing model instances (vs replacing) #955

Closed
benvinegar opened this issue Feb 4, 2012 · 7 comments
Closed
Labels

Comments

@benvinegar
Copy link

If I create a new model, and then call fetch, it will update that model's attributes.

If I create a collection of models, and then call fetch, it won't update the existing models – it will replace them with new instances.

This is painful because I cannot cache references to the collection's model instances, as the references become invalid once a fetch occurs. Instead I'd have to cache references to the collection, and do Collection#get every time I want to access the model. Maybe that's acceptable, but it seems reasonable that a collection should be able to perform a fetch/update without invalidating existing model instances.

@tbranyen
Copy link
Collaborator

tbranyen commented Feb 4, 2012

I could see an option being created for this, but the default behavior should still remain reset, imo.

@iros
Copy link
Contributor

iros commented Feb 4, 2012

How would you want to handle "add" events to the collection if you're only updating a model? Would you want your change event to fire instead? I can see situations where both would be valid behaviors (throw-away views vs carefully managed views etc.)
I think having a flag for this would be pretty swell.

@braddunbar
Copy link
Collaborator

Yes, I've implemented something like this, adding/removing as necessary instead of replacing. I call it a "soft" reset. It doesn't support updating the models but it certainly could. Very handy.

@tomasztunik
Copy link
Contributor

We've used custom extension to do exactly that in Wunderkit as well - 👍 from us on this one - and yes - it should be as an option rather then default behavior

edit: hm I'm wondering if we could implement kind of "sync" behavior here - for example a fetch returns same collection - but some models are gone, some are changed and some are added. Now it should not only check vs models if they already exist but it should also check if any models weren't removed so they should get removed from the collection as well. Something to think about :)

@vincentbriglia
Copy link

There used to be a pull request, I have not checked whether the snippet works with Backbone 0.9.1 but it should get you on track dalyons@0af0e23

vincentbriglia pushed a commit to vincentbriglia/backbone that referenced this issue Feb 10, 2012
update existing models
collection.fetch({update: true});
or
collection.update(models);

update existing models but prune missing
collection.fetch({update: true, prune: true});
or
collection.update(models, {prune: true});
@ruudk
Copy link

ruudk commented Feb 15, 2012

@dalyons Why is there no PR for this awesome feature? Because it works like a charm!

@jashkenas
Copy link
Owner

I'd be glad to entertain a pull request for "smart" resets, but -- they're already easy to accomplish with the tools backbone gives you: set(), changedAttributes(), _.isEqual, etc.

Furthermore, you'd have to deal with a number of API choices, most of which have no "right" answer:

  • If a model is present in the collection, but not in the response, do you delete it?
  • If a model is present in the response, but not in the collection, do you add it?
  • How does it work for infinite-scroll-style collections, where you're only fetching a window of models from the server?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

8 participants