Изменение моего backbone.js router

Question

У меня есть веб-приложение с require.js, backbone.js и jquery.
Краткая структура приложения выглядит следующим образом:

• Есть 2 секции на экране (панель инструментов и основной контент ниже).

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

• Существует один backbone.js маршрутизатор. Это сердце приложения. Маршрутизатор активируется с новым хеш-фрагментом (вручную введен, кнопка возврата, выбор пункта меню).

До сих пор в маршрутизаторе я делал переход страницы, я ПРЯМО звался контроллером («вид» в магистрали) выбранного компонента.

Таким образом, существует CENTRAL обработка вызова контроллера.

Но это должно измениться сейчас до диспетчеризации. Теперь мне нужно ответить на новый хеш-фрагмент из двух разных мест: от компонента панели инструментов и от маршрутизатора.
Итак, моя идея заключается в обмене механизмом вызова прямого контроллера с pub sub. Теперь компоненты MULTIPLE могут зарегистрироваться для специального действия, и маршрутизатор просто «запускает событие».

Я искал вокруг и нашел Чаплин (https://github.com/moviepilot/chaplin), пример приложения backbone.js.

Разработчики Чаплина, кажется, имеют похожую вещь под названием «ApplicationView» (https://github.com/moviepilot/chaplin#toc-router-and-route):

«Между маршрутизатором и контроллерами, есть ApplicationView в диспетчесркого.»

Есть ли кто-нибудь, кто уже имеет такую ​​архитектуру и может рассказать мне о своем опыте с этим или кто-нибудь решил это по-другому?

Answer 1

Я использовал аналогичную, хотя, возможно, менее сложную, архитектуру в this project. Я даю довольно хорошее объяснение в this answer to a related question. Краткий обзор:

• Я управляю приложения в масштабах события, которые изменяют состояние приложения, используя одноэлементную State модель, которая работает аналогично паб/к югу архитектуре Чаплина. Это всего лишь базовая модель Backbone, с некоторыми дополнительными методами обработки сериализации и десериализации атрибутов в виде строк, поэтому их можно установить в URL-адресе.

• Компоненты приложения, которые изменяют состояние приложения в ответ на взаимодействие пользователя или другой ввод, делают это путем установки свойств на app.state.

• Компоненты, которые необходимо обновить при изменении состояния приложения сделать это путем связывания с change событий на app.state (это выглядит именно так mediator работы Чаплина, хотя они переименовали методы, чтобы соответствовать паб/суб парадигму) ,

• Я рассматриваю свои маршрутизаторы как специализированные виды, которые обновляют адресную строку и отвечают на ввод пользователя в этой области. Изменение адреса (вручную или нажатие на ссылку) приводит к тому, что маршрутизатор должен set() внести необходимые изменения в модель app.state, а все остальное обновит соответствующим образом.

Надеюсь, это полезно - я думаю, что это немного проще, чем подход Чаплина.