Backbone.js: ¿dónde almacenar información del estado?

Question

Soy nuevo en Backbone.js, y estoy tratando de averiguar donde las variables de estado deberían vivir. Mi caso de uso:

Tengo una aplicación que proporciona una interfaz de lectura para un libro (lo sé, ejemplo clásico, ¿no?). Mis modelos son Book y Page con clases de colección para cada uno. La estructura de la aplicación se ve más o menos así (valga la visio ASCII):

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

Es decir, los Controller crea instancias y coordina dos puntos de vista, y IndexViewBookView, respaldados por los modelos. El BookView crea una instancia y coordina un conjunto de subvistas (de hecho, hay más de lo que se muestra aquí).

La información de estado incluye:

• el libro actual (puntero o id)
• la página actual (puntero o id)
• otras variables de estado de interfaz de usuario, como por ejemplo si las imágenes en la página son visibles o no, si otros widgets están abiertos o cerrados, etc.

Mi pregunta es, ¿dónde debería estar esta información de estado? Las posibles opciones incluyen:

• Los modelos , lo que podría tener en cuenta el estado. Esto tiene sentido, ya que están destinados a almacenar datos y las vistas pueden escuchar cambios de estado, pero no parece que esto se ajuste al patrón de Backbone.js deseado, y no siempre tendría sentido (por ejemplo, activar la imagen en la PageView debe aplicarse a todas las páginas, no sólo el actual)

• Un modelo Singleton especial destinado a recibir información de estado. Nuevamente, tiene sentido, es fácil de escuchar, todos los puntos de vista podrían vincularse a él, pero de nuevo, esto parece fuera del estándar MVC.

• Los vistas, que son responsables del estado de interfaz de usuario - pero esto requeriría vistas a tener en cuenta entre sí para obtener información de estado, que parece incorrecta

• El controlador , que debería ruta la aplicación entre estados: esto tiene sentido, pero implica un viaje de ida y vuelta algo extraño, por ejemplo User selects "Show Images" --> View event listener is called --> View informs Controller --> Controller updates state --> Controller updates View (en lugar de la simple User selects "Show Images" --> View event listener is called --> View updates)

supongo que de alguna manera esto es una cuestión genérica MVC, pero estoy teniendo problemas para conseguir mi cabeza alrededor de ella. ¿Qué parte de la aplicación debería ser responsable de guardar el estado actual?

ACTUALIZACIÓN: Para referencia futura, utilicé un modelo de estado singleton global para este problema.El flujo de interfaz de usuario es la siguiente:

1. manipuladores Ver IU no hacen más que actualizar app.State
2. Mis routers también hacer nada más que actualizar app.State - son vistas que muestran esencialmente especializados y reaccionan a los cambios de dirección URL
3. Vistas escuchar los cambios en app.State y actualizar en consecuencia

Mi aplicación es de código abierto - se puede ver el code on Github. La pieza relevante aquí es State model, que he extendido para tratar con (de) estado de serialización para la URL.

Answer 1

¿Por qué no crear un modelo de estado para almacenar y describir el estado actual? No creo que eso esté mal. Como el estado actual involucra a más de un modelo, creo que es razonable crear un modelo de estado para almacenar y recibir el estado actual.

El controlador podría comunicarse con el modelo de estado para obtener el estado actual. Sin embargo, los estados de IU deberían almacenarse en el modelo correspondiente. El modelo de estado sabe qué libro y qué página y luego el libro y los modelos de página llevan un registro de sus estados actuales de UI.

Answer 2

Don't limit your Backbone apps to Backbone constructs. Si encuentra que su aplicación necesita alguna funcionalidad que no se adapte bien a uno de los constructos de Backbone, no la meta en una sola por el simple hecho de mantener todo en Backbone.

He encontrado esto backbone boilerplate para ser útil a este respecto. Configura módulos para usted y le proporciona un objeto de aplicación que amplía Backbone.Events (como en el artículo previamente vinculado). Este objeto de la aplicación se puede utilizar para almacenar modelos, vistas y controladores/enrutadores instalados, y debe tener la libertad de agregar sus propios módulos no troncales al objeto de la aplicación, para encargarse de las responsabilidades que no encajan perfectamente en uno de los Construcciones de columna vertebral.