backbone.js - Backbone 路由器或 View 是否应该处理获取数据并显示加载状态？

Question

在我的应用程序的许多地方，都会发生以下模式:

用户点击某个链接触发导航

需要获取数据以呈现 View

UI 设计需要在获取数据时显示“加载”微调器

获取数据后，我们将显示渲染 View

我尝试了以下两种实现模式:

路由器处理获取

路由器告诉容器 View 显示加载微调器

路由器加载任何集合/模型

路由器告诉容器 View 隐藏加载微调器

路由器将集合/模型传递给 View 并呈现它

查看句柄获取

路由器只是创建和渲染 View

View 获取它需要的集合和模型

首次渲染 View 时，它只显示加载微调器，因为数据仍在加载

当数据到达时，模型/集合触发事件并且 View 绑定(bind)到这些事件，因此它会重新渲染自身，从而隐藏加载微调器并显示完整 View

我不喜欢#1，因为路由器变成了一个巨大的模型/集合获取逻辑球，并且似乎有太多的责任。 #2 似乎是更好的职责分配(路由器只是决定显示哪个 View ， View 确定它需要获取哪些数据)，但它确实使 View 呈现有点棘手，因为它现在是有状态的。

StackOverflow 社区是怎么想的？ 1、2还是别的什么？

Answer 1

这篇文章很老了，但我们今天早些时候正在审查它，所以以防其他人遇到它:

对我来说，我真的看到了两个不同的问题:

数据获取机制和结果 View 渲染应该发生在路由器还是 View 中？

View 应该期待已经解析的模型，还是应该响应可能仍在加载的模型？

我们处理它的方式与一些个人喜好混合在一起:

两者都没有，尽管我会更靠近路由器。路由器应该处理路由， View 应该处理查看，而其他东西应该处理模型/集合获取逻辑的机制和工作流程。我们称其为 Controller ，路由器基本上委托(delegate)给它。

正如尤里所暗示的，“有时”是现实。我认为这可能是个案决定，但最终应该是 Controller 和 View 之间的契约(Contract)，而不是路由器/ View 之间的契约(Contract)。

我喜欢 Yuri 的要点，有几个注意事项(缩进的项目符号):

路由器只知道将用户发送到哪里

外部 View 只知道用户应该查看什么(给定它的数据)

假设外部 View 特定于内部 View 的用例并且由另一个 View “拥有”(用于清理)

否则对于通用容器(例如渲染到“主”位置)，我们发现拥有一个管理页面上某个“部分” View 的组件很有用 - 我们称之为渲染器

内心的观点只知道如何只展示他们的一小部分(和
可以在其他地方使用)

并且渲染功能始终显示正确的内容。

对于通用容器，最终由渲染器负责

渲染器的主要原因是处理与该部分相关的事情，例如清理现有 View 以避免重影 View ，在渲染时滚动到顶部(我们的 MainContentRenderer 会这样做)，或者在这种情况下显示一个微调器。

一个可能看起来像的伪代码示例，用于:

一个通用的内容目标“主要”(如果它是特定于用例的，根据 Yuri 的示例，使用 ComponentView 可能会更好，具体取决于您的 View 生命周期管理策略)

我们必须获取并等待的模型

接受已加载模型的 View

路由器:

routes: {
    "profile": "showProfile"
},

showProfile: function() {
    return new ProfileController().showProfile();
}

配置文件 Controller :

showProfile: function() {
    //simple case
    var model = new Model();
    var deferredView = model.fetch.then(function() {
        return new View(model);
    };
    MainContentRenderer.renderDeferred(deferredView);
}

主要内容渲染器:

var currentView;

renderDeferred: function(deferredView) {
    showSpinner();
    deferredView.then(function(view) {
        this.closeSpinner();
        this.closeCurrentView();
        this.render(view);
    }
},

render: function(view) {
    currentView = view;
    $('#main-content').html(view.render().el);
}

closeCurrentView: function() {
    if (currentView and currentView.close()) {
        currentView.close();
    }
}

引入 Controller 还具有可测试性的额外好处。例如，我们有复杂的规则来执行围绕 URL 管理的搜索、在结果 View 和新搜索 View 之间进行选择，以及在缓存的“最后”搜索结果和执行新搜索之间进行选择。我们对 Controller 进行了 Jasmine 测试，以验证所有流逻辑是否正确。它还提供了一个隔离的地方来管理这些规则。