Backbone.js - где хранить информацию о состоянии?

Question

Я новичок в Backbone.js , и я пытаюсь выяснить , где должны находиться переменные состояния .Мой пример использования:

У меня есть приложение, которое предоставляет интерфейс для чтения книги (я знаю, классический пример, верно?).Мои модели Book и Page с классами коллекций для каждого.Структура приложения выглядит примерно так (простите за ASCII):

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

То есть Controller создает и координирует два вида, IndexView и BookView, поддерживаемые моделями,BookView создает и координирует набор подпредставлений (на самом деле их здесь больше, чем показано).

Информация о состоянии включает в себя:

• текущая книга (указатель или идентификатор)
• текущая страница (указатель или идентификатор)
• другие переменные состояния пользовательского интерфейса, например, являются ли изображения на странице видимыми или нет, открыты или закрыты другие виджеты и т. Д.

Мой вопрос: где должна храниться эта информация о штате?Возможные варианты:

• модели , которые могут быть осведомлены о состоянии.Это имеет некоторый смысл, поскольку они предназначены для хранения данных, и представления могут прослушивать изменения состояния, но не похоже, что это соответствует намеченному шаблону Backbone.js и не всегда имеет смысл (например, включение изображения вPageView должен применяться ко всем страницам, а не только к текущей)

• A специальная одноэлементная модель , предназначенная для хранения информации о состоянии.Опять же, имеет смысл, легко слушать, все представления могут связываться с ним - но опять же, это кажется вне стандартного MVC.

• views , которыеотвечает за состояние пользовательского интерфейса - но для этого требуется, чтобы представления были осведомлены друг о друге, чтобы получить информацию о состоянии, которая кажется неправильной

• Контроллер , который должен маршрутизироватьприменение между состояниями - это имеет смысл, но оно подразумевает немного странное путешествие туда и обратно, например 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)

Я думаю, в некотором смысле этообщий вопрос MVC, но у меня возникли проблемы с пониманием. Какая часть приложения должна отвечать за сохранение текущего состояния?

ОБНОВЛЕНИЕ: Для дальнейшего использования я использовал глобальную модель одноэлементного состояния для этой проблемы.Поток пользовательского интерфейса выглядит следующим образом:

1. Обработчики пользовательского интерфейса просмотра ничего не делают, кроме обновления app.State
2. Мои маршрутизаторы также ничего не делают, кроме обновления app.State - это по сути специализированные представления, которыеотображать и реагировать на изменения URL
3. Просматривать изменения можно на app.State и обновлять соответственно

Мое приложение с открытым исходным кодом - вы можете увидеть код на Github .Соответствующим элементом здесь является модель состояния , которую я расширил, чтобы иметь дело с (де) сериализацией состояния для URL.

Answer 1

Не ограничивайте свои приложения Backbone только конструкциями Backbone . Если вы обнаружите, что вашему приложению требуются некоторые функции, которые не вписываются в одну из конструкций Backbone, не включайте ее в один только ради сохранения всего в Backbone.

Я нашел этот базовый шаблон полезным в этом отношении. Он настраивает модули для вас и предоставляет вам объект приложения, который расширяет Backbone.Events (как в ранее связанной статье). Этот объект приложения можно использовать для хранения созданных экземпляров моделей, представлений и контроллеров / маршрутизаторов, и вы можете свободно добавлять свои собственные неосновные модули к объекту приложения, чтобы выполнять обязанности, которые не вписываются в одну из Магистральные конструкции.

Answer 2

Почему бы не создать модель состояния для хранения и описания текущего состояния?Я не думаю, что это неправильно.Поскольку текущее состояние включает более одной модели, я думаю, что разумно создать модель состояния для хранения и получения текущего состояния.

Затем контроллер может связаться с моделью состояния для получения текущего состояния.Хотя пользовательский интерфейс должен храниться в соответствующей модели.Модель состояний знает, какая книга и какая страница, а затем модели книги и страницы отслеживают свои текущие состояния пользовательского интерфейса.