Управление представлениями со сложными состояниями

Question

У меня есть приложение backbone.js, чьи представления имеют несколько состояний, которые существенно отличаются друг от друга («Вид», «Изменить» и т. Д.). Для каждого представления есть как минимум 2 разных шаблона. Хорошо. Моя проблема связана с кодом управления представлением JS.

Я полагаюсь на подход initalize-thin-render-thick (который, я думаю, очень плохой), где метод визуализации - это где 80% -90% логики. Когда я хочу изменить состояние, я просто вызываю метод визуализации с определенным параметром («просмотр», «редактирование»). Исходя из этого, мнение решает, что показывать, а что нет, к каким событиям привязываться и т. Д.

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

Я также заметил, что я не использую делегированную систему событий, предоставляемую магистралью, которая, как я думаю, является другим минусом, потому что я думаю, что она очень хорошо реализована (BTW, она обязательно отключает обратные вызовы, когда какой-то элемент DOM удален?)

Мне кажется, мне нужен серьезный рефакторинг. Пожалуйста, помогите с некоторыми советами относительно того, какой лучший подход для многогосударственного представления Backone.

Answer 1

То, что я делаю для этих случаев, состоит в том, чтобы сделать представление верхнего уровня, которое управляет подсмотром для каждого отдельного состояния (индекс, показать, редактировать и т. Д.). Когда вызывается действие пользователя, например, «отредактируйте этого пользователя», «удалите этого пользователя», «сохраните мои изменения», представление активного состояния сигнализирует маршрутизатору (напрямую или через гиперссылку), и маршрутизатор скажет, что представление верхнего уровня обновляет его состояние.

Продолжая пример редактора пользователей, предположим, что у меня есть представление верхнего уровня, называемое UserEditorView. Он отображает базовый контейнер для редактора пользователя (заголовков и т. Д.), А затем по умолчанию создает экземпляр и отображает Users.IndexView внутри этого контейнера.

Пользователи.IndexView отображает список пользователей. Рядом с каждым пользователем находится значок редактирования, который является ссылкой на «# users/555/edit». Таким образом, когда пользователь нажимает на нее, это событие переходит к маршрутизатору, который сообщает UserEditorView: «Эй, я хочу отредактировать пользователя # 555». И тогда UserEditorView удалит IndexView (путем вызова метода .remove()), создайте экземпляр Users.EditView для соответствующей модели пользователя и поместите EditView в контейнер.

Когда пользователь закончил редактирование пользователя, она нажимает «Сохранить», а затем EditView сохраняет модель. Теперь нам нужно вернуться к IndexView. EditView вызывает window.router.navigate ('users', {trigger: true}), поэтому URL-адрес обновляется и запускается маршрутизатор. Затем маршрутизатор вызывает .showIndex() в UserEditorView, а UserEditorView выполняет своп обратно в IndexView из EditView.

Answer 2

Простым способом управления выгрузкой событий я нашел this article on zombie views quite useful.

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

Чтобы сделать ваш рендер более тонким, я бы рекомендовал использовать маршруты. Они просты в настройке, и вы можете иметь разные виды для каждого маршрута. Или, что я привык делать, просто иметь разные шаблоны. Использование общего Backbone.View перезаписи:

Backbone.View = Backbone.View.extend({ 
    initialize: function(attrs) { 
     attrs = attrs || {} 
     if(!_.isUndefined(attrs.template)) { 
     this.template = attrs.template; 
     } 
    } 
}); 

Я заметил, что я повторно взгляды двух способов: 1.виды просмотра отличаются только базовой моделью и шаблоном, но не связанной с ней логикой (нажатие на кнопку submit проверяет и сохраняет модель) 2. тот же вид можно повторно использовать в нескольких местах с разными шаблонами (например, список пользователей как рейтинг или ваши счета)

С вышеуказанным расширением, я могу передать {template: '/ my/current/template /} в представление, и оно будет отображаться так, как я хочу. Вместе с маршрутами я наконец получил гибкую, понятную и тонкую настройку.