Какая гранулярность подходит для представлений Backbone.js?

Question

Я использую Backbone.js для визуализации небольшого угла существующего большого веб-приложения .Если все пойдет хорошо, я вижу, как Backbone.js расширяется, чтобы охватить все приложение, предоставляя некоторую столь необходимую структуру для органически выращенного приложения.Это предисловие.Теперь о проблеме:

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

Какова соответствующая гранулярность для каждогоВид? Я идентифицировал следующие «непослушные биты»:

• Сама вкладка, которая охватывает все содержащиеся в ней элементы управления.
• Поле выбора
• Описательныйтекст, который отвечает на поле выбора
• Календарь, который отвечает на поле выбора
• Виджет чтений, который отвечает на поле выбора, и содержит:
  • Опционально, кнопка «Пуск», которая активирует текущий план.
  • Когда активировано, один или несколько флажков, соответствующих отдельным показаниям в сегодняшней записи.
  • Когда активировано, кнопка «Далее», которая завершаетсегодняшняя запись и отображает следующую.

Должна ли каждая из этих точек маркера получить свой собственный вид? Только основные части (вкладка, блок выбора, виджет)?т приведет к довольно много просмотров.Первый кажется, что это может привести к слишком сложным реализациям View.Что лучше?

Примечание: Я понимаю, что это может быть истолковано как дико субъективный вопрос, но я все еще оборачиваюсь вокруг шаблонов Backbone.js и Javascript / DOM MVC, иЯ надеюсь, что есть более узкое «это то, что предназначено / работает лучше всего» от более опытных практиков Backbone.js.Спасибо!

Answer 1

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

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

Что касается обновлений модели и повторного рендеринга, вся идея Backbone состоит в том, чтобы отделить эту проблему от представлений. Модели генерируют события «изменения», когда их атрибуты изменяются, и какие бы то ни было представления на странице в данный момент, и отображают данные этой конкретной модели, будут уведомлены об изменении и могут обновить себя.

Answer 2

На ваш вопрос нет однозначного ответа. Вы можете взглянуть на гранулярность sproutcore для примеров.

Вы также можете посмотреть http://vimeo.com/17186379, где Йехуда Кац иллюстрирует трудности обновления различных частей страницы.

Один из способов посмотреть на это - проверить, какая часть должна быть обновлена ​​с другими изменениями / событиями модели, и попытаться минимизировать повторный рендеринг.

Извините, нет хороших ответов, как вы указали;)