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

Есть один основной принцип, который должен привести к созданию в основном разумных компонентов Marionette:

Вы всегда должны иметь возможность повторно выполнить рендеринг.

То есть вызов render() не должен приводить к изменению DOM. Модель DOM всегда должна отражать состояние экземпляра представления. Другими словами, если бы мы клонировали экземпляр представления в его текущем состоянии, а затем отображали его в другой части страницы, оба экземпляра должны отображать идентичную разметку. Мы определим несколько правил и передовых практик, которые естественным образом вытекают из этого принципа и помогут вам его достичь.

Просто визуализировать

Это правило также можно было бы назвать «не трогайте DOM». Непосредственное манипулирование DOM (добавление / удаление классов, изменение стилей, создание элементов и т. Д.) В вашем JavaScript приводит к паре нежелательных результатов:

  1. Ваше представление становится все труднее поддерживать и отлаживать, поскольку неясно, где могут происходить изменения состояния DOM.
  2. Очень легко получить несоответствие между тем, что показывает DOM, и сохраненным состоянием вашего представления.

Когда это происходит, некоторая часть состояния вашего компонента фактически сохраняется только в DOM, и повторный рендеринг компонента приведет к потере этой информации.

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

Плохо:

Хорошо:

Не сохранять состояние в DOM

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

Разбейте представления на небольшие логические компоненты

Есть много очевидных и часто упоминаемых преимуществ разбиения кода на более мелкие части. Его легче читать и поддерживать, он способствует повторному использованию кода, легче тестировать, помогает распараллеливать разработку… этот список можно продолжить. Поскольку это относится к нашему правилу всегда рендеринга вместо прямого обновления DOM, он помогает нам держать под контролем объем рендеринга и рендерить только то, что требуется.

Используйте магистральный маршрутизатор

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

Плохой:

Хорошо:

Предостережения

Конечно, из правил всегда есть исключения. Не всегда можно избежать обновления DOM за пределами render(). Например, иногда повторный рендеринг приводит к «скачку» пользовательского интерфейса или, возможно, к потере позиции прокрутки. Рендеринг для каждого изменения также означает, что вы не можете использовать какие-либо переходы. Постарайтесь ограничить эти ситуации небольшими частями просмотра, чтобы ограничить ущерб, и не помешает оставить комментарий, объясняющий, почему вы нарушаете общее практическое правило.

Заворачивать

Резюмируем:

  • Измените DOM, обновив переменные экземпляра и вызвав render()
  • Не обновляйте DOM по частям на протяжении всего представления
  • Сделайте как можно больше в шаблоне, при необходимости используйте onRender
  • Не сохранять состояние в DOM
  • Разбейте представления на небольшие подвиды
  • Используйте роутер

Если вы будете следовать этим основным рекомендациям и всегда спрашивать себя: «Если бы я переделал это представление прямо сейчас, что-нибудь изменилось бы?», Вы будете на пути к написанию некоторых разумно поддерживаемых представлений Backbone Marionette. Они кажутся простыми, но, даже если вы их знаете, их легко игнорировать, когда приближаются дедлайны, а время решающих задач уже не за горами. Ваше будущее (и коллеги) поблагодарит вас, если вы будете сопротивляться этому побуждению.