Backbone: Status da coleção e do modelo buscando / salvando etc.

Olá @ g00fy-! Eu recomendo que você use os eventos "request" e "sync" para este propósito. O que você acha?

collection.on('request', function() {
  // loading...
}).on('sync', function() {
  // display records or "none found"
});
collection.fetch();

_Editar - eu quis dizer o evento "request" , não "fetch" ._

Acho que é uma ótima ideia @braddunbar!

Obrigado @caseywebdev! :)

Informe-nos se isso não funcionar para você @ g00fy-.

@braddunbar , @caseywebdev a ideia é separar essas duas partes. (a visualização deve ser capaz de obter a coleção em qualquer estado, não apenas coleção _'clean'_)
Sei que posso fazer isso usando sinais, mas em muitos casos isso não pode ser feito dessa forma. A ordem das ações é importante

Eu concordo que o modo de exibição deve ouvir os sinais de 'solicitação' e 'sincronização', mas o sinal de solicitação pode ser enviado antes que a coleção seja passada para a exibição , portanto, o modo de exibição não tem ideia de que a coleção está buscando.

Considere um exemplo, onde sua visualização obtém uma coleção arbitrária. Esta coleção pode ser _fetched_, _fetching_ ou _unfetched_ quando é passada para a visualização (tl: dr veja o exemplo 3) .

Exemplo 1 (onde os sinais funcionarão)

collection = new Backbone.Collection();
view = new Backbone.View({collection:collection});
view.render();
// what should the view render ?
collection.fetch() // now sync signal gets sent

Exemplo 2 (a visualização já foi buscada, mas a coleção emty e os sinais também funcionarão)

collection = new Backbone.Collection();
collection.fetch();  // now sync signal gets sent
// after fetch completes
// view won't be able to receive 'sync' signal
view = new Backbone.View({collection:collection}); 
view.render(); 
// at this point collection.length == 0. 
// I guess the view can listen to 'sync' and then render 'empty' 

Exemplo 3 (mais importante, os sinais não funcionarão)

collection = new Backbone.Collection();
collection.fetch();  // now 'request' signal gets sent, but it is pending
// view won't be able to receive 'request' signal
view = new Backbone.View({collection:collection}); // at this point collection.length == 0
// view did not receive the 'request' signal, therefore has no idea that the collection is fetching
// and the view should render  'loading'
// after 2 seconds, 'sync' signal gets sent

O modo de exibição não deve presumir que, se collection.length == 0, então ele não foi buscado.
O modo de exibição também não deve presumir que é fornecida uma coleção no estado não buscado (ou em qualquer outro estado).

Se quisermos separar a coleção da visualização, a visualização deve ser capaz de saber qual é o estado da coleção.

a mesma coisa vale para o modelo

@ g00fy Se você não puder apenas fetch a coleção após enviá-la para a visualização, defina um sinalizador fetching ou algo semelhante em sua coleção.

collection.on({
  request: function () { this.fetching = true; },
  'sync error': function () { this.fetching = false; }
});

Agora sua view pode acessar this.collection.fetching e também esperar por this.collection para disparar o evento sync ou error .

@caseywebdev
A solicitação pode ser abortada ou duas solicitações podem ser enviadas de uma vez.

// example 1
collection.fetch().abort()  // and collection.fetching == true
// example 2 - don't care about abort();
collection.fetch();
collection.fetch();
// 1st request compleated
!!collection.fetching == false // but the 2nd request is pending - should it be loading or not?
// 2nd request completed

A solução para isso seria conectar do xhr adiado

collection.on({
    'request':function(model,xhr){ 
        this.fetching = true; 
        xhr.fail(function(){this.fetching = false }.bind(this));
    },
    'sync error': function () { this.fetching = false; }
});

É por isso que acho que seria útil ter isso integrado, mas, por outro lado, se cada aprimoramento como esse fosse aprovado, a base de código do BB seria inchada.

se cada aprimoramento como esse fosse aprovado, a base de código do BB seria inchada.

Acho que se trata menos de inchaço do que de abordagem. Existem muitas maneiras diferentes de lidar com solicitações simultâneas. O backbone fornece os primitivos de que você precisa para manipulá-los e, em seguida, sai do caminho.

@ g00fy- você pode querer dar uma olhada em como escrever uma máquina de estado finito para seus propósitos. Chaplin.js tem um que deve ser muito fácil de replicar, e também há ifandelse / machina.js (veja a postagem do