CODEWITHSUNDEEP
javascriptbackbone.jshttprequest
Jiayang
Jiayang

Reputation: 778

page renders before DELETE request is done

I'm working on a "todo app" Backbone client side. After I make a delete request in TodoView, it will be redirected to the index page(showing the whole list). The problem is that after redirecting, the deleted todo is still in the list. However it disappears after refreshing.

Is it because the todo list renders faster than the DELETE request being done?

In the todoView I listen to the 'delete' button:

events: {
  'click .red-button' : 'delete',
},

delete: function() {
  this.model.destroy({
    success: function(model, res) {
      $('.body-container').empty();
      //redirecting to the index page--the todo list
      navigate(''); //equals to Backbone.Router.prototype.navigate(url, {trigger: true}) 
    }
  })
},

I overrode sync for todo model. The 'delete' method is like:

case 'delete':
  request
    .del(this.url())
    .end(function(res) {
      console.log('deleting......');
    });
    options.success();
break;

Upvotes: 1

Views: 83

Answers (1)

Toli
Toli

Reputation: 5777

First, don't use the success callback! Very bad practice/it's a bad habit to get into for the future (see below for "why"). Backbone isn't "done" doing it's thing until it fires a destroy event. So listen to the model's destroy event. Cleaner are easier :)

delete: function(){
  this.model.destroy();
  //Ideally put this in your ROUTER
  this.listenTo(this.model, 'destroy', function(){
     navigate();
  }
}

However you're not done there. The most likely problem you have is that whatever list view is on the index page isn't listening to it's models' destroy events. Assuming you used ItemViews (individual Views) you would do

 var TodoView = Backbone.View.extend({
   initialize: function(){
     this.listenTo(this.model, 'destroy', this.remove);
   }
 });

That will fix the surface issue.

But in that case, you have a bigger underlying problem. Your ToDoList View from index page isn't properly getting removed when you navigate away. This causes a LOT of problems (especially once your application grows). Whenever a navigate event happens make sure ALL VIEWS are remove()d from the page. Very important!!!

If you post the code for your "index page" I can help you diagnose further.

WHY USING success callback is bad (Draft 1)

When you start building "real" applications on backbone generally there will be a LOT of views, models, and various objects "listening" for your model to be destroyed. You may have 5-10 different views listening to this model (in fact I've run into this situation in just about every enterprise app I've written). If you use the success callback, it becomes very confusing to track the chain of events that are happening. When an action (such as navigating away) happens they first (and only) place you want to look is the router. Otherwise, imagine there are 50-100 different "actions" that will cause a navigate to be fired, and they are all happening from the success callbacks of different models it will take you DAYS to track down why a certain navigate happened. If you let the object taking the action listenTo different objects, you have it centralized. I will explain this in a lot more detail later on (I know it seems confusing). But trust me on this one, you want to get away from using success.

Upvotes: 2

Related Questions