Разработка Backbone.js приложений

Разработка Backbone.js приложений
Автор: Эдди Османи
Год: 2014
ISBN: 978-5-496-00962-1
Страниц: 352
Язык: Русский
Формат: PDF
Размер: 10 Мб

Download

Backbone – это javascript-библиотека для тяжелых фронтэнд javascript-приложений, таких, например, как gmail или twitter. В таких приложениях вся логика интерфейса ложится на браузер, что дает очень значительное преимущество в скорости интерфейса.
Цель этой книги – стать удобным источником информации в помощь тем, кто разрабатывает реальные приложения с использованием Backbone. Издание охватывает теорию MVC и методы создания приложений с помощью моделей, представлений, коллекций и маршрутов библиотеки Backbone; модульную разработку ПО с помощью Backbone.js и AMD (посредством библиотеки RequireJS), решение таких типовых задач, как использование вложенных представлений, устранение проблем с маршрутизацией средствами Backbone и jQuery Mobile, а также многие другие вопросы.

+

Фрэнк Ллойд Райт однажды сказал: «Вы не можете изменить замысел архитектора, но вы можете открыть двери и окна для света, который видите». В этой
книге я надеюсь осветить тему улучшения структуры веб-приложений и распахнуть для вас двери в мир программ, которые будет удобно поддерживать и использовать.

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

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

Используя только библиотеки jQuery для разработки приложения, вы не сумеете изящно структурировать и организовать код, и ваше JavaScript-приложение
быстро превратится в причудливое месиво из селекторов и обратных вызовов jQuery, отчаянно пытающихся синхронизировать данные между HTML-компонентами пользовательского интерфейса, логикой JavaScript и обращениями к вашему API для работы с данными.

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

В этой книге я в компании с другими опытными авторами продемонстрирую, как улучшить структуру веб-приложений с помощью популярной JavaScript-библиотеки Backbone.jsверсии 1.0.

Что такое MVC?

Ряд современных JavaScript-фреймворков позволяет разработчикам легко организовывать свой код с помощью разновидностей паттерна под названием MVC (Model-View-Controller, модель-представление-контроллер). MVC делит задачи приложения па три части:

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

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

Тем не менее JavaScript-фреймворки, реализующие паттерн MVC, не всегда строго следуют ему. В одних решениях (в том числе и в Backbone.js) функции контроллера интегрированы в представление, в то время как другие решения содержат дополнительные компоненты.

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

В каких случаях необходим MVC-фреймворк на JavaScript?

Разрабатывая одностраничное JavaScript-приложение со сложным пользовательским интерфейсом или просто программу, сокращающую число НТТР-запросов при обновлении веб-страницы, вы, скорее всего, придете к созданию элементов, многие из которых входят в состав MV*-фреймворка.

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

Структурирование приложения — гораздо более масштабная задача, чем связывание воедино DOM-библиотеки, шаблонов и маршрутизации. Многие МУ*-фреймворки содержат не только элементы, которые вы могли бы написать сами, но и решения тех проблем, с которыми вы сталкиваетесь в процессе разработки. Фреймворки экономят ваше время и их не следует недооценивать.

Итак, когда же следует воспользоваться МУ*-фреймворком, а когда — нет?

Если вы создаете приложение, в котором отображение представлений и работа с данными происходят в основном в браузере, то МУ*-фреймворк окажется для вас полезным. Примерами таких приложений являются Gmail, News-Blur и мобильный клиент Linkedln.

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

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

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

Ключевые понятия

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

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

В этой главе мы изучим развитие паттерна проектирования «Модель-Представление-Контроллер» (Model-View-Controller, MVC) и узнаем, как библиотека Backbone.js использует этот шаблон в разработке клиентского приложения.

Паттерн MVC

MVC представляет собой паттерн проектирования архитектуры, который улучшает структуру приложения путем разделения его задач. Он позволяет изолировать бизнес-данные (модели) от пользовательских интерфейсов (представлений) с помощью третьего компонента (контроллеров), который управляет логикой и вводом пользовательских данных, а также координирует модели и представления. Исходный паттерн был создан Трюгве Реенскаугом (Trygve Reenskaug) в 1979 году во время его работы над языком Smalltalk-80 и назывался «Модель-Представление-Контроллер-Редактор» (Model-View-Controller-Editor). Паттерн MVC подробно описан в книге «Банды Четырех» (Gang of Four) под названием «Приемы объектно-ориентированного проектирования. Паттерны проектирования» (Design Patterns: Elements of Reusable Object- Oriented Software), вышедшей в 1994 году и способствовавшей популяризации его использования.

MVC во Всемирной паутине

Всемирная паутина в значительной степени опирается на протокол HTTP, у которого нет внутреннего состояния. Это означает, что не существует постоянно открытого соединения между браузером и сервером: каждый запрос приводит к созданию нового канала связи между ними. Как только сторона, инициировавшая запрос (например, браузер), получает ответ, соединение закрывается. Такой контекст отличается от контекста операционных систем, в котором разрабатывались многие изначальные идеи MVC. Реализация MVC должна соответствовать веб-контексту.

Примером фреймворка для серверных веб-приложений, в котором сделана попытка применения MVC-подхода в контексте Всемирной паутины, является Ruby on Rails (рис. 2.1).

Ядро этого фреймворка составляет архитектура на основе трех знакомых нам MVC-компонентов: модели, представления и контроллера. В Rails они имеют следующий смысл:

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

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

MVC на клиентской стороне и одностраничные приложения

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

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

Когда пользователь переходит к новому представлению, приложение обращается за дополнительным содержимым для этого представления с помощью запроса XHR (XMLHttpRequest), как правило, к серверному REST API или конечной точке. AJAX (Asynchronous JavaScript and XML, асинхронный JavaScript и XML) обеспечивает асинхронное взаимодействие с сервером, при котором передача и обработка данных происходит в фоновом режиме без вмешательства в работу пользователя с другими частями страницы. Это делает интерфейс более быстрым и удобным.

Одностраннчпые приложения могут использовать такие возможности браузера, как API журнала для обновления поля адреса при перемещении из одного представления в другое. Эти URL также позволяют пользователям создавать закладки на определенных состояниях приложения и обмениваться ими без необходимости загружать совершенно новые страницы.

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

Основы Backbone

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

Подготовительные действия

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

Вставьте в ваш текстовый редактор следующий текст и замените закомментированную строку между тегами <script> на JavaScript-код любого интересующего примера:

Ваше первое приложение на Backbone.js

Теперь, когда мы изучили необходимые основы, давайте напишем первое приложение на Backbone.js. Мы создадим приложение для управления задачами, размещенное на сайте TodoMVC.com. Разработка списка задач — отличный способ попрактиковаться в Backbone (рис. 4.1). Это относительно простое приложение, однако технические нюансы, касающиеся связывания его компонентов, сохранения данных моделей, маршрутизации и отображения шаблонов, позволяют проиллюстрировать ряд ключевых возможностей библиотеки Backbone.

Рассмотрим общую архитектуру нашего приложения. Нам потребуется:

  • модель, описывающая отдельные задачи;
  • коллекция TodoList для хранения задач;
  • способ создания задач;
  • способ отображения списков задач;
  • способ редактирования существующих задач;
  • способ помечать задачу как завершенную;
  • способ удаления задач;
  • способ фильтрации завершенных и незавершенных задач.

В сущности, перечисленные возможности представляют собой классические CRUD-методы (create/read/update/delete, создание/чтение/обновление/ удаление). Итак, начнем!