Question

我正在开发一个“todo app”Backbone客户端。在TodoView中发出删除请求后，它将被重定向到索引页面（显示整个列表）。 问题是在重定向后，删除的待办事项仍然在列表中。然而，它在刷新后消失了。

是因为 todo列表渲染速度比DELETE请求的速度要快吗？

在todoView中我听'删除'按钮：

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}) 
    }
  })
},

我覆盖了todo模型的同步。 '删除'方法如下：

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

Answer 1

首先，不要使用success回调！非常糟糕的做法/它是一个养成未来的坏习惯（见下文＆＃34;为什么＆＃34;）。骨干不是＆＃34;完成＆＃34;做它的事情直到它发起destroy事件。所以听听模特的破坏事件。清洁剂更容易：）

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

但是你没有在那里完成。最可能的问题是索引页面上的任何列表视图都没有收听它的模型＆＃39; destroy个事件。假设你使用了ItemViews（个别视图），你会做

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

这将解决表面问题。

但在这种情况下，你有一个更大的潜在问题。当您离开时，索引页面中的ToDoList视图无法正确删除。这会导致很多问题（特别是应用程序增长后）。每当导航事件发生时，确保所有视图都是remove() d页面。非常重要!!!

如果您发布＆＃34;索引页面的代码＆＃34;我可以帮助你进一步诊断。

为什么使用success回调不好（草案1）

当你开始构建＆＃34;真实＆＃34;骨干上的应用程序一般会有很多视图，模型和各种对象＆＃34; listen＆＃34;为你的模型销毁。你可能有5-10种不同的观点来听这个模型（实际上我已经在几乎所有我写过的企业应用程序中遇到过这种情况）。如果您使用success回调，则跟踪正在发生的事件链会变得非常混乱。当一个动作（例如导航离开）发生时，它们首先（并且仅）放置你想看的路由器。否则，想象有50-100种不同的行动＆＃34;这将导致导航被触发，并且它们都是从不同模型的success回调中发生的，它将花费你DAYS来追踪某个导航发生的原因。如果让对象采取行动listenTo不同的对象，则将其集中。稍后我将详细解释这一点（我知道它似乎令人困惑）。但请相信我，你想要放弃使用success。

DELETE请求完成之前的页面呈现

1 个答案: