2012-10-05 7 views

Odpowiedz

36

Ok, więc tutaj jest to, co zrobiłem

ja zapisując fetch żądania w zmiennej

app.fetchXhr = this.model.fetch(); 

W moim routerze, mam funkcję, która dba o zamknięciu poglądy i renderowania widoki . Dba również o wyzwalanie wszelkich wyzwalaczy wymaganych dla każdej zmiany widoku, ale nie ma to znaczenia w tym pytaniu.

Zanim cokolwiek, to funkcja routera wykonuje następujące

//Stop pending fetch 
if(app.fetchXhr.readyState > 0 && app.fetchXhr.readyState < 4){ 
    app.fetchXhr.abort(); 
} 

Mam nadzieję, że to pomoże

+0

Mam powiązany problem, ale mam więcej niż jedną kolekcję. Zanim przerwiemy żądanie, muszę mieć pewność, że jest on powiązany z określoną kolekcją. Zadałem to pytanie tutaj, być może już poradziłeś sobie z tym problemem? http://stackoverflow.com/questions/21919690/association-between-backbone-collection-and-xhr-object-created-when-fetching – wuliwong

+0

Nie zaimplementowałem tego jeszcze, ale jedną rzeczą, którą możesz spróbować, to przechowywać wszystkie xhr żądania w tablicy. Na każdym żądaniu xhr lub przy każdej zmianie widoku możesz przechodzić przez tablicę, aby usunąć te, które są kompletne i zatrzymać te, które chcesz zatrzymać. To powinno zapewnić odpowiednie oczyszczenie. – Xerri

4

Zakładam, że używasz szkieletu z jQuery. Jeśli tak, to następujące pytanie wydaje się stanowić odpowiedź dla Ciebie:

Abort Ajax requests using jQuery

Backbone fetch zwraca xhr Mówią o, IIRC.

+0

ale nie przyniosą xhr zwrotu po zakończeniu? Nie wiesz, jak użyć linku, który podałeś do implementacji w Backbone – Xerri

+0

Backbone używa normalnych wywołań ajax (przez Zepto lub jQuery), co oznacza, że ​​wywołanie na serwer jest asynchroniczne i nadal może być potencjalnie zakończone. – JayC

-3

Prawdopodobnie późną odpowiedź :)

Wykorzystanie limitu czasu, aby określić wartość limitu czasu. Spowoduje to wyłączenie funkcji błędu. Tutaj zapytanie może zostać przerwane.

Czy istnieje jakiś powód, dla którego chcesz przerwać zapytanie?

+0

Chciałbym przerwać, ponieważ jeśli zmienię widok przed zakończeniem zapytania, błąd zostanie wygenerowany po zakończeniu pobierania i usunięciu widoku. – Xerri

9

Jeszcze jedna spóźniona odpowiedź na wypadek, gdyby ktoś inny się na to natknął.

Skończyło się na zastąpieniu Backbone.sync, aby dodać pulę obiektów XHR i opcję przerwania oczekujących żądań przy pobieraniu.

var sync = Backbone.sync 
    , xhrPool = []; 

Backbone.sync = function(method, model, options) { 
    options = options || {}; 
    if (method === 'read') { 
    if (options.abortPending == true) {  
     for (var i = 0; i < xhrPool.length; i++) { 
     if (xhrPool[i]['readyState'] > 0 && xhrPool[i]['readyState'] < 4) { 
      xhrPool[i].abort(); 
      xhrPool.splice(i, 1); 
     } 
     } 
    } 

    // cleanup xhrPool 
    // todo: make removal from the pool an 'always' jqXHR callback 
    // instead of cleanup on every read? 
    for (var i = 0; i < xhrPool.length; i++) { 
     if (xhrPool[i]['readyState'] === 4) { 
     xhrPool.splice(i, 1); 
     } 
    } 

    var xhr = sync(method, model, options); 
    xhrPool.push(xhr); 
    return xhr; 
    } else { 
    return sync(method, model, options); 
    } 
}; 
+0

Bardzo fajnie .... może nie być elastyczne, jeśli wykonujesz wiele żądań pobierania w określonym widoku. FYI ... Jednym z powodów, dla których tego potrzebowałem, było uniknięcie błędów generowanych po zakończeniu pobierania, ale widok się zmienił (więc element DOM, który zawierał dane, już nie istnieje). Prosta próba/catch wokół pobierania naprawiła to. – Xerri

Powiązane problemy