Kręgosłup.js-gdzie przechowywać informacje o stanie?

Jestem nowy w kręgosłupie.js, a ja próbuję rozgryźć gdzie powinny mieszkać zmienne stanu. Mój przypadek użycia:

Mam aplikację, która zapewnia interfejs do czytania książki (wiem, klasyczny przykład, prawda?). Moje modele to Book i Page z klasami kolekcji dla każdego. Struktura aplikacji wygląda mniej więcej tak (wybacz ASCII visio):

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

Czyli Controller tworzy i koordynuje dwa widoki, IndexView i BookView, poparte modelami. BookView tworzy instancje i koordynuje zestaw podwidywań(jest ich więcej niż pokazano tutaj).

Informacje o stanie obejmują:

• bieżąca Księga (wskaźnik lub id)
• bieżąca strona (wskaźnik lub id)
• inne zmienne stanu interfejsu użytkownika, takie jak to, czy obrazy na stronie są widoczne, czy nie, czy inne widżety są otwarte lub zamknięte, itp.

Moje pytanie brzmi, gdzie powinna mieszkać ta informacja o stanie? Możliwe opcje include:

• Modele , które mogą być świadome stanu. Ma to jakiś sens, ponieważ są one przeznaczone do przechowywania danych i widoki mogą nasłuchiwać zmian stanu, ale wydaje się, że nie pasuje to do zamierzonego szkieletu.JS, i nie zawsze miałoby to sens (np. włączanie obrazka w PageView powinno dotyczyć wszystkich stron, a nie tylko bieżącej)

• A specjalny model singleton przeznaczony do przechowywania informacji o stanie. Znowu ma sens, łatwy do słuchania, wszystkie widoki mogą się z nim wiązać - ale znowu, wydaje się to poza standardowym MVC.

• Aby uzyskać informacje o stanie UI, trzeba mieć świadomość, że widoki są ze sobą powiązane, co wydaje się niepoprawne

• Kontroler , który powinien kierować aplikację między Stanami - ma to sens, ale zakłada nieco dziwną podróż w obie strony, np. User selects "Show Images" --> View event listener is called --> View informs Controller --> Controller updates state --> Controller updates View (zamiast prostszego User selects "Show Images" --> View event listener is called --> View updates)

Myślę, że w pewnym sensie jest to ogólne Pytanie MVC, ale mam problem z opanowaniem tego. która część aplikacji powinna być odpowiedzialna za zapisywanie bieżącego stanu?

UPDATE: w przyszłości użyłem globalnego modelu singleton State dla tego problemu. Przepływ interfejsu wygląda tak:

1. Obsługa interfejsu nie robi nic poza aktualizacją app.State
2. moje Routery nie robią nic poza aktualizacją app.State - są to zasadniczo wyspecjalizowane widoki, które wyświetlają i reagują na zmiany adresu URL]}
3. odsłuchuje zmiany na app.State i odpowiednio aktualizuje

Moja aplikacja jest Open Source - możesz zobaczyć kod na Githubie. Istotnym elementem jest model stanu , który rozszerzyłem, aby zająć się (de)serializowaniem stanu dla adresu URL.