Backbone: Statut de récupération/enregistrement de la collection et du modèle, etc.

Salut @g00fy-! Je vous recommande d'utiliser les événements "request" et "sync" à cette fin. Qu'est-ce que tu penses?

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

_Modifier - Je voulais dire l'événement "request" , pas "fetch" ._

Je pense que c'est une super idée @braddunbar !

Merci @caseywebdev ! :)

Faites-nous savoir si cela ne fonctionne pas pour vous @g00fy-.

@braddunbar , @caseywebdev l'idée est de découpler ces deux parties. (la vue devrait pouvoir obtenir la collection dans n'importe quel état, pas seulement la collection _'clean'_)
Je suis conscient que je peux le faire en utilisant des signaux, mais dans de nombreux cas, cela ne peut pas être fait de cette façon. L'ordre des actions compte

Je suis d'accord que view doit écouter les signaux "request" et "sync", mais le signal de requête peut être envoyé avant que la collection ne soit transmise à view , donc view n'a aucune idée que la collection est en train de récupérer.

Prenons un exemple, où votre vue obtient une collection arbitraire. Cette collection peut être soit _fetched_ , _fetching_ ou _unfetched_ lorsqu'elle est passée à la vue (tl:dr voir exemple 3 ) .

Exemple 1 (où les signaux fonctionneront)

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

Exemple 2 (la vue est déjà récupérée, mais la collection emty, les signaux fonctionneront également)

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' 

Exemple 3 (le plus important, les signaux ne fonctionneront pas)

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

View ne doit pas supposer que si collection.length == 0, il n'est pas récupéré.
View ne doit pas non plus supposer qu'il reçoit une collection dans un état non récupéré (ou dans tout autre état).

Si nous voulons dissocier la collection de la vue, alors la vue doit être capable de savoir quel est l'état de la collection.

la même chose vaut pour le modèle

@g00fy Si vous ne pouvez pas simplement fetch la collection après l'avoir envoyée à la vue, définissez un indicateur fetching ou autre sur votre collection.

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

Maintenant, votre vue peut accéder à this.collection.fetching et attendre également this.collection pour déclencher l'événement sync ou error .

@caseywebdev
La demande peut être abandonnée ou deux demandes peuvent être envoyées à la fois.

// 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

La solution à cela serait de connecter do différé xhr

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

C'est pourquoi, je pense que cela pourrait être pratique d'avoir cela intégré, mais d'un autre côté, si chaque amélioration comme celle-ci réussissait, la base de code BB serait gonflée.

si chaque amélioration comme celle-ci réussissait, la base de code BB serait gonflée.

Je pense qu'il s'agit moins de ballonnements que d'approche. Il existe de nombreuses manières différentes de gérer les demandes simultanées. Backbone vous fournit les primitives dont vous avez besoin pour les gérer, puis s'en débarrasse.

@g00fy- vous voudrez peut-être jeter un œil à l'écriture d'une machine à états finis pour vos besoins. Chaplin.js en a un qui devrait être assez facile à reproduire, et il y a aussi ifandelse/machina.js (voir l' article de blog ) qui peut convenir à votre cas d'utilisation spécifique.