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

Question

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

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

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

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

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

Answer 1

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

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

Users.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

Об одном простом способе управления выгрузкой событий я нашел эту статью о зомби-представлениях весьма полезной .

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

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

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

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

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