javascript Backbone.js - 在哪里存储状态信息？

Backbone.js - where to store state information?

提问by nrabinowitz

I'm new to Backbone.js, and I'm trying to figure out where state variables should live. My use case:

我是Backbone.js 的新手，我想弄清楚状态变量应该在哪里。我的用例：

I have an application that provides a reading interface for a book (I know, classic example, right?). My models are Bookand Pagewith collection classes for each. The structure of the application looks roughly like this (forgive the ASCII visio):

我有一个为一本书提供阅读界面的应用程序（我知道，经典的例子，对吧？）。我的模型Book和Page每个模型都有集合类。应用程序的结构大致如下（请原谅 ASCII visio）：

+------------+
| Controller |
+------------+
    |      Views                 Models
    | +--------------+      +----------------+
    |-|  IndexView   |------| BookCollection |
    | +--------------+      +----------------+
    |                               |
    | +--------------+      +----------------+
    +-|   BookView   |------|     Book       |
      +--------------+      +----------------+
       |                            |
       | +--------------+           |
       |-|  TitleView   |-+         |
       | +--------------+ | +----------------+
       |                  +-|     Page       |
       | +--------------+ | +----------------+ 
       +-|   PageView   |-+
         +--------------+ 

That is, the Controllerinstantiates and coordinates two views, IndexViewand BookView, backed by the models. The BookViewinstantiates and coordinates a set of subviews (there are actually more than shown here).

也就是说，Controller实例化和协调两个视图，IndexView和BookView，由模型支持。该BookView实例化和坐标一组子视图（这里包括以上所示）。

State information includes:

状态信息包括：

• the current book (pointer or id)
• the current page (pointer or id)
• other UI state variables, such as whether images on the page are visible or not, whether other widgets are open or closed, etc.

• 当前书籍（指针或 id）
• 当前页面（指针或id）
• 其他 UI 状态变量，例如页面上的图像是否可见，其他小部件是打开还是关闭等。

My question is, where should this state information live? Possible options include:

我的问题是，这个状态信息应该存放在哪里？可能的选项包括：

• The models, which could be state-aware. This makes some sense, since they're intended to store data and views could listen for state changes, but it doesn't seem like this fits the intended Backbone.js pattern, and wouldn't always make sense (e.g. turning image on in the PageViewshould apply to all pages, not just the current one)

• A special singleton modelintended to hold state information. Again, makes sense, easy to listen to, all the views could bind to it - but again, this seems outside standard MVC.

• The views, who are responsible for the UI state - but this would require views to be aware of each other to get state info, which seems incorrect

• The controller, which should route the application between states - this makes sense, but it implies a slightly odd round trip, e.g. User selects "Show Images" --> View event listener is called --> View informs Controller --> Controller updates state --> Controller updates View(rather than the simpler User selects "Show Images" --> View event listener is called --> View updates)

• 该模型，这可能是状态感知。这是有道理的，因为它们旨在存储数据并且视图可以侦听状态更改，但这似乎不符合预期的 Backbone.js 模式，并且并不总是有意义（例如在对PageView应适用于所有的网页，而不仅仅是当前的）

• 一种特殊的单例模型，用于保存状态信息。再次，有意义，易于聆听，所有视图都可以绑定到它 - 但同样，这似乎超出了标准 MVC。

• 该意见，谁负责的UI状态-但是这需要意见，了解彼此的获得状态信息，这似乎不正确

• 该控制器，它应该路由应用程序的状态-这是有道理的，但它意味着一个有点奇怪的往返，例如User selects "Show Images" --> View event listener is called --> View informs Controller --> Controller updates state --> Controller updates View（而不是简单User selects "Show Images" --> View event listener is called --> View updates）

I guess in some ways this is a generic MVC question, but I'm having trouble getting my head around it. What part of the application should be responsible for saving the current state?

我想在某些方面这是一个通用的 MVC 问题，但我无法理解它。应用程序的哪个部分应该负责保存当前状态？

UPDATE:For future reference, I used a global singleton State model for this problem. The UI flow goes like this:

更新：为了将来参考，我对这个问题使用了全局单例状态模型。UI 流程是这样的：

1. View UI handlers do nothing but update app.State
2. My routers also do nothing but update app.State- they're essentially specialized views that display and react to URL changes
3. Views listen to changes on app.Stateand update accordingly

1. 视图 UI 处理程序除了更新什么都不做 app.State
2. 我的路由器除了更新什么都不做app.State——它们本质上是专门的视图，显示 URL 更改并对其做出反应
3. 视图监听更改app.State并相应更新

My app is Open Source - you can see the code on Github. The relevant piece here is the State model, which I've extended to deal with (de)serializing state for the URL.

我的应用程序是开源的 - 你可以在 Github 上看到代码。这里的相关部分是State 模型，我已经对其进行了扩展以处理 URL 的（反）序列化状态。

采纳答案by Ragnar

Why don't create a state model to store and describe the current state? I don't think that is wrong. Since the current state involves more than one model I think it's reasonable to create a state model to store and receive the current state.

为什么不创建一个状态模型来存储和描述当前状态？我不认为这是错误的。由于当前状态涉及多个模型，我认为创建一个状态模型来存储和接收当前状态是合理的。

The controller could then communicate with the state model to get the current state. The UI states should be stored in the corresponding model though. The state model knows which book and which page and then the book and page models keep track of their current UI states.

然后控制器可以与状态模型通信以获取当前状态。UI 状态应该存储在相应的模型中。状态模型知道哪本书和哪一页，然后书和页模型会跟踪它们当前的 UI 状态。

回答by tex

Don't limit your Backbone apps to Backbone constructs. If you find that your app needs some functionality that doesn't fit well into one of Backbone's constructs, don't shoehorn it into one just for the sake of keeping everything in Backbone.

不要将您的 Backbone 应用程序限制为 Backbone 结构。如果您发现您的应用程序需要一些不适合 Backbone 结构之一的功能，请不要仅仅为了将所有内容都保留在 Backbone 中而将其硬塞进一个。

I've found this backbone boilerplateto be helpful in this respect. It sets up modules for you and provides you with an app object that extends Backbone.Events (like in the previously-linked article). This app object can be used to store instantiated models, views and controllers/routers, and you should feel free to add your own non-backbone modules to the app object, to take care of responsibilities that don't fit perfectly into one of the Backbone constructs.

我发现这个主干样板在这方面很有帮助。它为您设置模块并为您提供一个扩展 Backbone.Events 的应用程序对象（如之前链接的文章中所述）。此应用程序对象可用于存储实例化的模型、视图和控制器/路由器，您可以随意将自己的非主干模块添加到应用程序对象中，以处理不完全适合其中之一的职责主干结构。