MarionetteJS + Поздний завтрак, часть 2 - точка входа в приложение

Эта статья является частью серии о MarionetteJS и Brunch.io. Хотя я стараюсь, чтобы статьи были как можно более абстрактными, чтобы они не слишком сильно зависели от предыдущих, я бы посоветовал вам прочитать все предыдущие статьи, поскольку я буду объяснять множество концепций, которые могут помочь вам лучше понять статьи. < br />
‹ Предыдущее
Следующее ›

Привет, ребята,

Это было давно, работа отнимала очень много времени, и у меня никогда не было времени продолжить серию, но я надеюсь, что теперь могу поддерживать стабильную скорость загрузки: D

В предыдущей статье мы говорили о первых шагах, необходимых для запуска нашего приложения, требованиях, настройке brunch.io и получении шаблона, поэтому сейчас мы сосредоточимся на MarionetteJS.

В качестве первой записи мы поговорим о Mn.Application (ради экономии времени и продления срока службы клавиатуры я буду называть MarionetteJS просто Mn). Раньше у backbone не было четкой точки входа для вашего приложения, поэтому многие люди изо всех сил пытались понять, где они будут выполнять все те задачи, которые вы явно хотите выполнить прежде всего, например, запуск вашего Router или получение некоторые исходные данные. Это может привести к принятию некоторых неверных решений, особенно если вы зависите от порядка загрузки для создания экземпляров данных.

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

Вот пример использования Mn.Application:

//Imports `Application` from MarionetteJS
import { Application } from 'backbone.marionette'
//Extends Application as your entry-point
const App = new Application.extends({
   region: '#app',
   onStart(){
      ...
   }
});
//Starts new Application when DOM is loaded
document.addEventListener('DOMContentLoaded', () => {
   const app = new App();
   app.start();
});

Как видите, это очень легко сделать, и, держу пари, вы можете получить очень хорошее представление о том, что происходит!

Жизненный цикл приложения

Возможно, вы заметили метод onStart() и предположили, что его цель - инициализировать то, что вы хотите, при первом запуске приложения, верно?

Ну и что? Вы правы!

onStart() - это метод, который принадлежит Mn.Application жизненному циклу, и его цель действительно инициализировать данные при первом запуске приложения, но это не единственный метод. Mn.Application имеет два метода в рамках своего жизненного цикла: onStart и onBeforeStart.

На этом этапе вы можете (а можете и не думать, просто предположим, что вы ради моего так прекрасно написанного сценария: P) думаете примерно так:

«Но, эй, какова цель этих двух разных жизненных циклов? Разве я не могу, вроде бы, делать все внутри того или иного? »

Что ж, вы определенно можете, и в этом нет ничего плохого (например, поломки вашего приложения), но подумайте об этом. Наша первая проблема заключалась в следующем: «Куда я буду класть все эти вещи, которые мне нужно загрузить, прежде всего», верно? Эта проблема была решена с помощью Mn.Application, и это здорово, но это не обязательно означает, что вы на 100% защищены от проблем, связанных с инициализацией приложений.

Почему? Что ж, вам все равно нужно убедиться, что вы инициализировали все в правильном порядке! Представьте, что ваш первый Mn.View использует конкретный Bb.Model (если вы догадались, чтоBb обозначает Backbone, вы на правильном пути), но вы создаете экземпляр только Bb.Model после Mn.View, тогда ваше приложение, скорее всего, все равно выйдет из строя. Чтобы попытаться решить эту «проблему», создатели Mn создали два разных метода жизненного цикла для разделения этой логики, поэтому по соглашению в onBeforeStart это место, где вы захотите настроить такие вещи, как маршрутизатор, модели, сбор и начальный выборка данных, а в onStart отображение ваших представлений и инициализация Bb.History. Поступая так, вы можете испортить инициализацию вашего приложения, только если вы все еще не уверены в порядке загрузки событий или если вы на самом деле не читали статью: |

Область приложения и расположение корня

Возможно, вы заметили клавишу region в приведенном выше примере кода и, возможно, задаетесь вопросом, что это такое, поскольку я могу согласиться с тем, что это единственное, что в коде может быть не самоочевидным.

Я расскажу о regions более подробно в другой статье, но в целом Mn.Regions - это отличный способ управлять различными частями вашего представления. До Mn v3 было определенное представление с именем LayoutView (на данный момент каждое представление - aMn.View), и, как вы, наверное, догадались, оно использовалось специально для определения макета вашего приложения.

Давайте посмотрим на пример ниже:

Мы могли бы определить наш LayoutView, чтобы он содержал все эти разные разделы, и каждый раздел был бы Mn.Region, так что в итоге мы получим что-то вроде:

regions: {
   headerRegion : '#header'
   navRegion    : '#navigation'
   mainRegion   : '#main'
   sidebarRegion: '#sidebar'
   footerRegion : '#footer'
}

Регионы определяются внутри Mn.View с использованием вышеуказанной конфигурации, простого объекта с ключом regions, а затем списка из key-value элементов, где key - это имя, которое вы хотите дать этому региону, а value - это селектор jQuery. фактически существующего элемента в DOM (отсутствие элемента в DOM даст вам лучшую историю ужасов, чем ИТ).

Это чрезвычайно полезно для повторного рендеринга представления. Допустим, вы отрендерили все свои представления во всех своих регионах. В хорошие дни, если у вас было как представление контактов и представление о, когда вы хотели переключаться между ними, вам приходилось повторно отображать всю страницу, даже хотя footer, header, sidebar и navigation на обеих страницах по-прежнему одинаковы, что снижает производительность. Да, вы могли бы сделать это с помощью JavaScript, но это было не очень приятно.

Но если вы используете Mn.Region, это больше не проблема, вы можете сохранить свои footer, header, sidebar и navigation регионы нетронутыми, а затем повторно визуализировать main region только с помощью контакта или шаблонов, что сделает ваше приложение более производительным, ваш код чище и избегает дублирования кода.

Mb.Application - это ваша точка входа, поэтому вполне естественно, что вы хотите определить для нее основную область и корневой макет в качестве родительского для всех остальных регионов и макетов. По этой причине в Mnv3 появилось 2 новых способа сделать это: атрибут region и метод showView().

Мы говорили о том, как регионы определены внутри Mn.View, но Mn.Application является исключением, позволяющим вам создать «родительский регион» для всего вашего приложения, при этом применяются те же правила.

showView() - это метод, специально разработанный для рендеринга RootView или RootLayout (как бы вы его ни называли) внутри «родительской области». Это RootView - просто нормальный вид с определенными областями для визуализации всех остальных видов (изображение выше - очень хороший пример RootView). Это также должно быть единственное представление, которое будет отображаться внутри вашего Mn.Application и все остальные виды отображаются внутри него.

Доступ к прикрепленным областям и представлениям

Итак, теперь у нас есть инициализированное приложение, и день стал ярче, но осталось только одно: как мне получить доступ к определенному региону или представлению внутри региона после инициализации приложения?

Что ж, Mn.Application предоставляет нам 2 простых метода для этого:

- getRegion(<region_name>): этот метод позволяет нам получить доступ к региону, передав его имя в качестве аргумента. Теперь мы можем получить доступ ко всей структуре внутри него.

- getView(): этот метод позволяет нам получить доступ к представлению внутри региона, поэтому после того, как вы используете getRegion() для доступа к региону, вы можете связать getView() для доступа к представлению внутри него.

Вот и все, теперь вы очень хорошо понимаете, что такое Mn.Application и как его использовать. Надеюсь, вам понравилась статья и она была вам чем-то полезна.

Не стесняйтесь задавать любые вопросы, и я надеюсь поймать вас, ребята, в моей следующей статье.

Ваше здоровье ;)