为什么在backbone.js的导航函数中调用trigger:true被认为是不好的做法？

我在几个地方读到过，调用Backbone.history.navigate函数被认为是不好的做法

例如，Addy Osmani sais在他的书《开发主干网.js应用程序》中写道

Router.navigate（）也可以触发沿途的路由 通过传递trigger:true选项更新URL片段。 注意：不鼓励这种用法

或者德里克·贝利在他甚至说：

大多数情况下，您不应该从应用程序中执行路由的处理程序

但我真的不明白背后的原因，还有什么更好的解决办法

---

在我看来，使用trigger:true选项调用navigate函数并不是一件坏事。调用route函数时，可以始终检查所考虑的数据是否已加载，并显示此加载的数据，而不是重新执行整个工作…

在我看来，这被认为是不好的做法，因为您应该想象主干应用程序不像Ruby On Rails应用程序，而是像桌面应用程序

当我说RoR时，我只是说一个支持路由的框架，从某种意义上说，路由将您带到控制器的特定调用，以运行特定的操作（想象一个CRUD操作）

Backbone.history仅用作用户的书签，以便用户可以保存特定的url，稍后再次运行。在这种情况下，他会发现与以前一样的情况

当你说：

在我看来，用 触发器：true选项。route函数在调用时始终可以 检查所考虑的数据是否已加载，并显示已加载的数据 数据，而不是重新做整个工作

对我来说那听起来很臭。如果您正在触发路由，并且正在检查数据以查看是否有路由，这意味着您实际上已经有了路由，因此您应该相应地更改视图，而无需再次加载具有相同数据的整个DOM

也就是说，

trigger:true

是否存在我们有理由使用它？在我看来，如果完全交换视图，就可以使用它

假设我有一个带有两个选项卡的应用程序，一个允许我创建单个资源，另一个允许我查看已创建资源的列表。在第二个选项卡中，您实际上正在加载一个集合，因此这两个选项卡之间的数据不同。在这种情况下，我将使用

触发器：true

---

也就是说，我已经使用主干网两周了，所以我对这个世界很陌生，但对我来说，阻止使用这个选项听起来很合理。

我不同意@Stephen的回答。主要原因是使用

router.navigate（{trigger:true}）

让路由器负责处理应用程序的状态。它应该只反映应用程序状态，而不是控制它

另外，更改窗口的哈希值不是

视图的责任，这是路由器的唯一任务！别把它拿走！良好的模块化和关注点分离使应用程序具有可扩展性和可维护性

将某人转发到应用程序中的新分区
主干是一个事件驱动的框架，使用事件进行通信。完全不需要调用
router.navigate（{trigger:true}）
，因为功能不应该在路由器中。下面是我如何使用路由器的一个例子，我认为它促进了良好的模块化和关注点分离

var Router = Backbone.Router.extend({
  initialize: function(app) {
    this.app = app;
  },
  routes: {
    'videoLibrary' : function() { this.app.videoLibrary(); }
  }
});

var Application = _.extend({}, Backbone.Events, {
  initialize: function() {
    this.router = new Router( this );
    this.listenTo( Backbone, 'video:uploaded', function() { 
      this.router.navigate('/videoLibrary');
      this.videoLibrary();
    });
  },
  videoLibrary: function() {
    //do useful stuff
  }
});

var uploadView = Backbone.View.extend({
  //...
  uploadVideo: function() {
    $.ajax({
      //...
      success: function() { Backbone.trigger('video:uploaded'); }
    });
  }
});

您的视图不需要或不想知道当用户完成上传时该做什么，这是其他人的责任。在本例中，路由器只是应用程序功能的入口点，由
uploadView
生成的事件是另一个。路由器始终通过哈希更改和历史记录反映应用程序状态，但不实现任何功能

可测试性
通过分离关注点，您增强了应用程序的可测试性。在主干上设置间谍很容易。触发

并确保视图正常工作。模拟路由器不太容易

模块管理

---

此外，如果使用AMD或CommonJS等模块管理，则必须在应用程序中的任何位置传递路由器实例，才能调用它。因此，在您的应用程序中实现紧密耦合并不是您想要的。

我认为，关于

路由器#导航

的确切功能，似乎存在一些困惑

如果没有设置任何选项，它会将URL更新为提供的片段。 例如，

router.navigate（'todo/4/edit'）

将更新URL至

#todo/4

，并将为该URL创建浏览器历史记录条目未运行任何路由处理程序

但是，设置

trigger:true

将更新URL，但它也将运行为该路由指定的处理程序（在Addy的示例中，它将调用路由器

editto

函数）并创建浏览器历史记录条目

传递

replace:true

时，url将被更新，不会调用任何处理程序，但不会创建浏览器历史记录条目

那么，我认为答案是：

不鼓励使用

trigger:true

的原因很简单，从一个应用程序状态导航到另一个应用程序状态需要运行与直接导航到特定应用程序状态不同的代码

假设您的应用程序中有状态A、B和C。但B国建立在A国的基础上，C国建立在B国的基础上。 在这种情况下，当您从B导航到C时，只需要执行代码的特定部分，而当hi