I have a collection that I'd like to refresh from the server, but a simple collection.fetch() resets the collection briefly causing all of my related views to get destroyed and recreated. I tried collection.fetch({add: true})which solves the issue of my views getting destroyed and recreated, but if the server passes back updated data for an existing model it doesn't get updated. Is there something i'm missing that isn't a reset, but instead will make the same call to the server and update all of my models?
As a temporary solution I'm using collection.fetch({add: true}) and then collection.each(function(model) { model.fetch() }), which works for all situations except a model being removed, but for 10 models it requires 11 round trips to the server and fetches all of the same data twice.
I had same problem and this is my solution.
I have 2 collections. One is only for rendering and doesn't have even have
url property. Second have it and I call it's .fetch method when needed.
When this second collection triggers reset, I search for new models (which
are in second collection but not in first) and for deleted (which are in
first collection, but not in second).
Since I only check if there are new or deleted models, it is quite fast. If
you need to check if some models changed, it would take longer.
On Sep 14, 2012 5:51 PM, "Asa Ayers" <asa.ay...@gmail.com> wrote:
> I have a collection that I'd like to refresh from the server, but a simple
> collection.fetch() resets the collection briefly causing all of my related
> views to get destroyed and recreated. I tried collection.fetch({add:
> true}) which solves the issue of my views getting destroyed and
> recreated, but if the server passes back updated data for an existing model
> it doesn't get updated. Is there something i'm missing that isn't a reset,
> but instead will make the same call to the server and update all of my
> models?
> As a temporary solution I'm using collection.fetch({add: true}) and then collection.each(function(model)
> { model.fetch() }), which works for all situations except a model being
> removed, but for 10 models it requires 11 round trips to the server and
> fetches all of the same data twice.
If you are not polling the server for changes made by other users and instead are just redrawing your collection to reflect changes made by the current user then I would recommend not polling the server, just add items to the dom in response to successful saves on models, and deletes or updates of course. Doing a server fetch can also be done as a diff, use a cached collection for your views and compare what you quietly fetch onto a temp collection not bound to any views, if it differs then redraw your views by swapping the fetched collection into your cached one which should trigger a change event.
On Friday, September 14, 2012 7:50:58 PM UTC+6, Asa Ayers wrote:
> I have a collection that I'd like to refresh from the server, but a simple > collection.fetch() resets the collection briefly causing all of my related > views to get destroyed and recreated. I tried collection.fetch({add: > true}) which solves the issue of my views getting destroyed and > recreated, but if the server passes back updated data for an existing model > it doesn't get updated. Is there something i'm missing that isn't a reset, > but instead will make the same call to the server and update all of my > models?
> As a temporary solution I'm using collection.fetch({add: true}) and then collection.each(function(model) > { model.fetch() }), which works for all situations except a model being > removed, but for 10 models it requires 11 round trips to the server and > fetches all of the same data twice.
Thanks for the suggestions. My hack of a solution was to use .fetch({ add: true, success: function(collection, response) { ... } }) and my success handler loops over the collection deleting anything not found in the response. I'll probably try this cached collection idea, my implementation requires knowledge of how to parse the response from the server, so it's not going to be portable between projects.
On Saturday, September 15, 2012 5:51:20 AM UTC-4, Alistair K Macdonald wrote:
> If you are not polling the server for changes made by other users and > instead are just redrawing your collection to reflect changes made by the > current user then I would recommend not polling the server, just add items > to the dom in response to successful saves on models, and deletes or > updates of course. Doing a server fetch can also be done as a diff, use a > cached collection for your views and compare what you quietly fetch onto a > temp collection not bound to any views, if it differs then redraw your > views by swapping the fetched collection into your cached one which should > trigger a change event.
Now when you do a collection.fetch with {update: true}, existing models are updated, new ones added and those deleted are removed. It works pretty well.
On Monday, September 24, 2012 6:02:01 PM UTC+5:30, Asa Ayers wrote:
> Thanks for the suggestions. My hack of a solution was to use .fetch({ add: > true, success: function(collection, response) { ... } }) and my success > handler loops over the collection deleting anything not found in the > response. I'll probably try this cached collection idea, my implementation > requires knowledge of how to parse the response from the server, so it's > not going to be portable between projects.
> On Saturday, September 15, 2012 5:51:20 AM UTC-4, Alistair K Macdonald > wrote:
>> If you are not polling the server for changes made by other users and >> instead are just redrawing your collection to reflect changes made by the >> current user then I would recommend not polling the server, just add items >> to the dom in response to successful saves on models, and deletes or >> updates of course. Doing a server fetch can also be done as a diff, use a >> cached collection for your views and compare what you quietly fetch onto a >> temp collection not bound to any views, if it differs then redraw your >> views by swapping the fetched collection into your cached one which should >> trigger a change event.
