Доступно множество библиотек JavaScript, и большинство из них действительно хороши для обеспечения традиционных DOM-ориентированных взаимодействий, которые нужны вашим типичным веб-сайтам. Но когда пришло время создать управляемую кодовую базу для одностраничного приложения, вот тут-то и появился целый набор новых фреймворков, чтобы сгладить ситуацию.
Старая поговорка верна: «Используйте лучший инструмент для этой задачи».
Дело не в том, что традиционные библиотеки, такие как jQuery, не могут помочь вам в создании интерфейсов, подобных настольным компьютерам, это просто не вариант использования для этого, и в нем отсутствуют такие вещи, как привязка данных, маршрутизация событий и управление состоянием. Конечно, вы, вероятно, можете собрать кучу плагинов для достижения некоторых из этих функциональных возможностей, но, на мой взгляд, более разумно начинать с фреймворка, специально созданного с нуля для решения этих конкретных проблем. Старая поговорка верна: «Используйте лучший инструмент для этой задачи».
Недавно я дал интервью команде Ember.js ; это было мотивировано моим желанием узнать то, что я назвал «новой жаркостью»: Ember.js .
Ember отвечает всем тем, что я описал выше, и делает это таким образом, который во многом напоминает, как jQuery позволяет разработчикам быстро приступить к работе. Команда намеренно предприняла шаги, чтобы абстрагироваться от многих сложностей, присущих проектированию и созданию приложений на основе Model / View / Controller, используя многолетний опыт и знания, полученные при создании крупномасштабных приложений.
Что я хотел бы сделать, так это помочь вам освоиться с Ember.js через серию статей, состоящую из нескольких частей, которая постепенно познакомит вас с концепциями фреймворка. Мы начнем с обычного вступления (которое является этим постом), а затем постепенно перейдем к созданию полноценного приложения. Самое замечательное в том, что это также поможет мне закрепить концепции, которые я уже выучил, и, возможно, подберет некоторые новые методы на этом пути! Я сделаю все возможное, чтобы команда Ember.js проверила этот материал на точность и, возможно, даже внесла в него некоторые самородки.
Прежде чем мы продолжим, вспомните: Ember.js делает много магии для вас. Бывают случаи, когда вы смотрите на код и говорите: «А? Как он это сделал?» Я был там, и я сделаю все возможное, чтобы разобраться, но я не собираюсь погружаться в недра фреймворка Ember. Вместо этого я расскажу, как вы можете использовать его инструменты и API для создания своего приложения.
Итак, давайте начнем.
Основные понятия
Ember.js не является основой для создания традиционных веб-сайтов.
Первое, что нужно иметь в виду, это то, что Ember.js не является основой для создания традиционных веб-сайтов. Такие библиотеки, как jQuery и MooTools, отлично подходят для этого. Если вы рассматриваете Ember.js, то предполагаете, что вы хотите создавать настольные приложения, особенно масштабируемые. Фактически, слоган для фреймворка — это «фреймворк для разработки амбициозных веб-приложений», который говорит вам, что это явно не библиотека JavaScript вашего папы.
Ранее я упоминал, что Ember использует шаблон MVC для продвижения правильного управления кодом и организации. Если вы никогда не занимались разработкой на основе MVC, вам обязательно стоит ознакомиться с ней. Nettuts + имеет отличную статью на эту тему здесь . Для тех из вас, кто знаком с концепциями, вы должны чувствовать себя как дома. Единственное, что я постоянно слышал, это то, что переход от Backbone к Ember.js на самом деле прост, потому что Ember делает для вас большую работу, сохраняя при этом шаблоны организации кода, к которым привыкли эти разработчики.
Ember также использует клиентские шаблоны … МНОГО . Он использует библиотеку шаблонов Handlebars, которая предоставляет выражения, позволяющие создавать динамические шаблоны на основе HTML. Разработчик Ember может связывать данные с этими встраиваемыми выражениями и динамически изменять отображение своего приложения на лету. Например, я могу создать шаблон, который может принимать массив людей и отображать их в неупорядоченном списке:
|
1
2
3
4
5
|
<ul>
{{#each people}}
<li>Hello, {{name}}!</li>
{{/each}}
</ul>
|
Обратите внимание на выражение «#each», которое работает как директива цикла, перечисляя каждый элемент массива people и заменяя выражение {{name}} «фактическим значением. Важно отметить, что двойные скобки — это токены, используемые Handlebars для идентификации выражений. Это небольшой пример, и мы подробнее рассмотрим его позже.
Handlebars — это невероятно мощный шаблонизатор на стороне клиента, и я бы рекомендовал ознакомиться не только с руководствами Ember , но и с самим сайтом Handlebars, чтобы получить полное представление о доступных параметрах. Вы будете использовать это совсем немного.
Настройка Ember
Ember.js использует дополнительные библиотеки, поэтому вам нужно взять копию jQuery и Handlebars . Но, подожди, разве я не сказал, что jQuery и Ember играют в разных местах? Ну, да, я сделал, но вот в чем дело: команда Ember — это не изобретать велосипед. Они выбрали jQuery, чтобы делать то, что лучше всего: работать с DOM. И это хорошо, поскольку JQuery действительно хорош в этом. Именно поэтому они пошли с Handlebars, отличной библиотекой шаблонов, написанной Иегудой Кацем, членом основной команды Ember.
Самый простой способ получить нужные вам файлы — это зайти в репозиторий Ember.js Github и снять Starter Kit . Это шаблон для вас, чтобы начать с. На момент написания статьи он содержал:
- Ember 1.0 RC1
- Handlerbars 1.0 RC3
- JQuery 1.9.1
Существует также базовый HTML-шаблон, который закодирован для включения всех связанных библиотек (jQuery, Ember и т. Д.), А также пример шаблона Handlebars и «app.js», который включает код для запуска базового приложения Ember. ,
|
1
|
<script src=»js/libs/jquery-1.9.1.js»></script> <script src=»js/libs/handlebars-1.0.0-rc.3.js»></script> <script src=»js/libs/ember-1.0.0-rc.1.js»></script> <script src=»js/app.js»></script>
|
Просто отметьте, что app.js не является частью фреймворка. Это простой файл JavaScript; Вы можете назвать это как угодно. И, хотя мы будем использовать его для целей этой учебной серии, в дальнейшем вы, скорее всего, в конечном итоге разделите свой JavaScript на несколько файлов, как и для любого другого сайта или приложения. Кроме того, Ember не ожидает определенной структуры каталогов для ваших файлов инфраструктуры.
Когда вы смотрите на код Starter Kit, он может выглядеть как ваш типичный код веб-сайта. В некоторых отношениях вы правы! Однако, как только мы начнем организовывать вещи, вы увидите, как отличается создание приложения Ember.
Кусок тлеющей земли
Прежде чем приступить к взлому кода, важно понять, как работает Ember.js, и что вы ухватились за движущиеся части, составляющие приложение Ember. Давайте посмотрим на эти части и как они связаны друг с другом.
Шаблоны
Шаблоны являются ключевой частью определения вашего пользовательского интерфейса. Как я упоминал ранее, Handlebars — это клиентская библиотека, используемая в Ember, а выражения, предоставляемые библиотекой, широко используются при создании пользовательского интерфейса для вашего приложения. Вот простой пример:
|
1
2
3
|
<script type=»text/x-handlebars»>
<h2><strong>{{firstName}} {{lastName}}</strong></h2>
</script>
|
Обратите внимание, что выражения смешиваются с вашей разметкой HTML и через Ember динамически изменяют содержимое, отображаемое на странице. В этом случае заполнители {{firstName}} и {{lastName}} будут заменены данными, полученными из приложения.
Handlebars предлагает много возможностей благодаря гибкому API. Вам будет важно понять, что он предлагает.
Маршрутизация
Маршрутизатор приложения помогает управлять состоянием приложения.
Маршрутизатор приложения помогает управлять состоянием приложения и ресурсами, необходимыми пользователю для навигации по приложению. Это может включать такие задачи, как запрос данных из модели, подключение контроллеров к представлениям или отображение шаблонов.
Вы делаете это, создавая маршрут для определенных мест в вашем приложении. Маршруты определяют части приложения и связанные с ними URL-адреса. URL — это ключевой идентификатор, который Ember использует, чтобы понять, какое состояние приложения необходимо представить пользователю.
|
1
2
3
|
App.Router.map( function() {
this.route( ‘about’ );
});
|
Поведение маршрута (например, запрос данных из модели) управляется с помощью экземпляров объекта маршрута Ember и запускается, когда пользователь переходит к определенному URL-адресу. Примером может быть запрос данных из модели, например так:
|
1
2
3
4
5
|
App.EmployeesRoute = Ember.Route.extend({
model: function() {
return App.Employee.find();
}
});
|
В этом случае, когда пользователь переходит в раздел приложения «/ employee», маршрут делает запрос модели на получение списка всех сотрудников.
модели
Объектное представление данных.
Модели — это объектное представление данных, которые ваше приложение будет использовать. Это может быть простой массив или данные, динамически извлекаемые из RESTful JSON API через запрос Ajax. Библиотека Ember Data предлагает API для загрузки, отображения и обновления данных для моделей в вашем приложении.
Контроллеры
Контроллеры обычно используются для хранения и представления данных и атрибутов модели. Они действуют как прокси, предоставляя вам доступ к атрибутам модели и позволяя шаблонам получать к ним доступ для динамической визуализации отображения. Вот почему шаблон всегда будет подключен к контроллеру.
Главное, что нужно помнить, это то, что, в то время как модель извлекает данные, контроллер — это то, что вы будете использовать для программного представления этих данных различным частям вашего приложения. Хотя может показаться, что модели и контроллеры тесно связаны, на самом деле сами модели не знают контроллеров, которые будут их использовать позже.
Вы также можете хранить другие свойства приложения, которые необходимо сохранить, но не нужно сохранять на сервере.
Взгляды
Представления в Ember.js предназначены для управления событиями, связанными с взаимодействием с пользователем, и преобразования их в события, имеющие значение в вашем приложении. Таким образом, если пользователь нажимает кнопку, чтобы удалить сотрудника, представление отвечает за интерпретацию этого события щелчка в браузере и его надлежащую обработку в контексте текущего состояния вашего приложения.
Соглашения об именах
Один из способов, с помощью которого Ember.js помогает минимизировать объем необходимого кода и обрабатывать его за кулисами, — это соглашения об именах. То, как вы определяете и называете свои маршруты (и ресурсы), влияет на наименование ваших контроллеров, моделей, представлений и шаблонов. Например, если я создаю маршрут под названием «сотрудники»:
|
1
2
3
|
App.Router.map( function() {
this.resource( ’employees’ );
});
|
Затем я бы назвал свои компоненты, например:
- Объект маршрута: App.EmployeesRoute
- Контроллер: App.EmployeesController
- Модель: App.Employee
- Вид: App.EmployeesView
- Шаблон: сотрудники
Использование этого соглашения об именах служит двойной цели. Во-первых, это дает вам семантические отношения между одинаковыми компонентами. Во-вторых, Ember может автоматически создавать необходимые объекты, которые могут не существовать (например, объект маршрута или контроллер), и подключать их для использования в вашем приложении. Это та «магия», о которой я упоминал ранее. Фактически, это именно то, что Ember делает на глобальном уровне Application, когда вы создаете экземпляр объекта Application:
var App = Ember.Application.create ();
Эта единственная строка создает ссылки по умолчанию на маршрутизатор, контроллер, представление и шаблон приложения.
- Объект маршрута: App.ApplicationRoute
- Контроллер: App.ApplicationController
- Вид: App.ApplicationView
- Шаблон: приложение
Возвращаясь к маршруту «сотрудники», который я создал выше, произойдет следующее: когда пользователь перейдет к «/ employee» в вашем приложении, Ember будет искать следующие объекты:
- App.EmployeesRoute
- App.EmployeesController
- шаблон сотрудников
Если он не найдет их, он создаст экземпляр каждого из них, но просто не будет ничего визуализировать, поскольку вы не указали модель для получения данных или шаблон для отображения данных. Вот почему соглашение об именах так важно. Это позволяет Ember знать, как справляться с задачами, связанными с конкретным маршрутом, без необходимости ручного подключения.
Обратите внимание, что в первом примере я использовал единственное имя «Сотрудник» для определения модели. Это специально. Сама природа имени «Сотрудники» предполагает, что я могу работать с 0 до многих сотрудников, поэтому важно создать модель, которая могла бы обеспечить гибкость для возвращения одного сотрудника или всех сотрудников. Соглашение об именовании в этой модели не является обязательным требованием Ember, поскольку сами модели не знают контроллеров, которые будут использовать их позже. Таким образом, у вас есть гибкость в присвоении им имен, но для согласованности соблюдение этого соглашения значительно облегчит управление вашим кодом.
Кроме того, я решил использовать метод resource () для определения своего маршрута, потому что в этом сценарии у меня, скорее всего, были бы вложенные маршруты для управления страницами сведений для конкретной информации о сотруднике. Мы поговорим о вложении позже в серии.
Ключевым выводом является то, что используя последовательную схему именования, Ember может легко управлять хуками, связывающими эти компоненты вместе, без необходимости явно определять отношения через тонну кода.
Полная информация об именных соглашениях Ember представлена на сайте проекта и является обязательной для прочтения .
Next Up: Создание приложения
В следующей части серии мы углубимся в код, чтобы создать основу для нашего приложения.
Мы рассмотрели основные концепции Ember и обсудили ключевые аспекты структуры. В следующей части серии мы углубимся в код, чтобы создать основу для нашего приложения. А пока я хочу еще раз порекомендовать вам начать смотреть документацию по Handlebars, чтобы понять синтаксис выражений. Кроме того, если вам не терпится попасть в Ember, следите за обновлениями на Tuts + Premium , который скоро предложит вам полный курс, который проведет вас через создание приложения на основе Ember!
Как я уже отмечал в начале этой статьи, ведущие сотрудники Ember.js Йехуда Кац и Том Дейл проверили это на точность и одобрили. Команда Ember одобрена! Скоро увидимся!