Подкаст SitePoint № 145: Основы Backbone.js с Адди Османи

Адди: Все, что я бы посчитал нетривиальным. Итак, допустим, у нас есть простое приложение для создания фотогалереи, которое, возможно, не использует единую парадигму приложения, и люди будут обновлять свою страницу каждый раз, когда они взаимодействуют с чем-то. Так что, если я нажму на миниатюру, чтобы просмотреть увеличенную версию изображения, я могу перейти на совершенно другую страницу, это может означать, что я делаю больше запросов http, мне нужно, чтобы пользователь ждал еще дольше чтобы загрузить, и в парадигме одностраничного приложения, которая, как правило, помогает людям с такими структурами, как Backbone, это означает, что нужно меньше кликов, чтобы все заработало, это означает, насколько быстро работает интерфейс, но с точки зрения организации вашего кода это означает что я могу аккуратно разбить различные компоненты, составляющие это приложение. Итак, мне ясно, что такое концепция фотографии в этом приложении? Что ж, я могу использовать модели, чтобы смоделировать данные вокруг этого и сказать, хорошо, ну, у фотографии может быть подпись, у фотографии может быть источник изображения, у нее могут быть некоторые дополнительные метаданные, хорошо, это концепция модели. Коллекция, которая есть у нас в Backbone, вероятно, представляет собой несколько разных моделей, поэтому это означает, что если у меня будет галерея, у меня будет несколько моделей, то есть несколько фотографий, в этой конкретной галерее. И мои взгляды могут, по сути, означать «хорошо», хорошо, что я на самом деле представляю конечному пользователю, я беру их со страницы индекса, которая может просто сказать, что делает приложение, и беру что-то, что может фактически позволить им пройти и просмотрите различные коллекции изображений, например, маршрутизация, возможно, будет использоваться для фактического переноса их с одной страницы на другую и предоставления им URL-адресов, очистки URL-адресов, если вы используете HTML5 PushState для простого использования хештегов для фактической навигации по приложению не заставляя их как бы обновлять страницу вообще.

Луи: Точно.

Адди: Так что это один пример.

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

Адди: Да.

Луи: И он ведет себя немного больше как серверное приложение, или как мы привыкли разрабатывать объектно-ориентированный код.

Адди: Точно, да. Итак, мы просто взглянули на пример приложения галереи, которое может быть реализовано с использованием Backbone и MVC. Теперь идея MVC на внешнем интерфейсе заключается в том, что он по-прежнему разделяет приложения на три основные проблемы. Прежде всего, у вас есть модели, которые управляют поведением данных приложения, и оно не сильно отличается от того, как обрабатываются данные, как модели обрабатываются на стороне сервера, они по-прежнему представляют собой знания и данные, на которые они по-прежнему реагируют. изменения состояния, но они, как правило, немного более изолированы от использования контроллеров, чем вы можете найти на стороне сервера. В таких средах, как Backbone, модели могут иногда группировать вещи и коллекции, поэтому у вас есть идея, что одна модель может представлять фотографию, но на самом деле коллекция в Backbone представляет несколько моделей или несколько фотографий. У вас могут быть представления, которые отвечают за сортировку моделей в форму, подходящую для взаимодействия с пользователем. Во многих случаях во внешнем интерфейсе ваши представления будут рассматриваться как ваш пользовательский интерфейс, они обычно отображаются в определенных элементах пользовательского интерфейса, поэтому у меня может быть div на странице, на который я на самом деле хочу представить свое представление, и это Можно назвать контейнером или чем-то еще, и я просто сделаю так, что независимо от того, использую я для этого библиотеку шаблонов или использую собственный внутренний материал Backbone, я просто собираюсь отображать это представление для определенного элемента. И у вас может быть несколько видов, которые предназначены только для отдельных моделей, поэтому у вас могут быть модели, представляющие фотографии в ваших приложениях, и у вас могут быть виды, которые, возможно, отображают различные аспекты этой модели. Итак, если у меня есть фотография, на которой есть метаданные, говорящие, вы знаете, ну, эта фотография была сделана, скажем, в Италии, например, эта фотография была сделана в 1990 году, там были Том, Дик и Гарри; у вас может быть один вид, который на самом деле показывает вам людей, которые были рядом, когда была сделана эта фотография, у вас может быть другой вид, который представляет место, где была сделана эта фотография, и, возможно, показывает вам карту, и так далее, и так далее. Затем у вас есть своего рода контроллеры на передней панели. Теперь, когда мы говорим о JavaScript, некоторые фреймворки не обязательно реализуют контроллеры, контроллеры обычно сортируют входные данные, могут инструктировать модели или представления и соответственно реагировать, поэтому обычно они сидят между моделями и представлениями, и они могут выполнять некоторую бизнес-логику и манипуляции данными, но они низки внутри MVC, это довольно сильно меняется. Вы обнаружите, что Backbone рассматривает контроллеры совсем по-другому; они фактически заменяют его идеей маршрутизатора для обработки навигации. Другие фреймворки могут поддерживать нечто, называемое контроллером, поэтому они представляют собой JavaScript MVC-фреймворки, которые должны делать что-то совершенно другое. Таким образом, существует много общего между MVC на стороне сервера и на стороне клиента, но обычно это сторона контроллера, в которой вещи отличаются от большинства, я бы сказал.

Луи: Точно. И, возможно, чтобы немного расширить идею представления, если кто-то не знаком с шаблонизацией JavaScript и с тем, как это работает, я знаю, что, вероятно, еще есть много разработчиков JavaScript, которые либо просто создадут встроенные DOM-узлы в своем коде. или загрузите целые куски HTML с сервера, не могли бы вы немного рассказать о шаблонах и о том, как они используются в этих средах?

Адди: О, абсолютно. Таким образом, использование шаблонов вообще, даже вне JavaScript MVC-фреймворков, очень полезно для ваших приложений. Один из способов, с помощью которого разработчики склонны подходить к этому без шаблонов, это то, что вы можете создавать HTML для своей страницы в памяти, используя катонирование сценариев, и я видел, как люди делают это; десять лет назад люди делали это в доктрине правильно, теперь, если вы не используете лучшие практики, есть люди, которые как бы объединяют десять или более строк кода, а затем внедряют это в страницу или внедряют каждый раз, когда новая линия строится в памяти, и проблема в том, что она не только неэффективна с точки зрения производительности, но и сложна в обслуживании. Итак, как только вы начинаете хранить несколько длинных строк, которые, как предполагается, представляют своего рода HTML, на вашей странице, и вы начинаете создавать большие приложения, может быть трудно понять, хорошо, какую часть моей страницы я сохранил сценарий в котором содержатся те строки, которые необходимо обновить сейчас. Что-то, что немного лучше и проще в управлении, но и более производительно, использует JavaScript-шаблоны. Итак, с использованием шаблонов JavaScript вы посмотрите, какой воспроизводимый вывод вы получаете в своем приложении, поэтому вместо того, чтобы я сказал «хорошо», у меня есть сервер JSON, поступающий из моего бэкэнда, который содержит несколько фотографий, что я собираюсь сделать Я собираюсь перебрать каждую из этих фотографий, и я собираюсь объединить некоторые теги изображений вокруг этого и некоторые вложенные div-ы вокруг этого, и я собираюсь создать себе псевдо-шаблон, который добавляет мою страницу. Вместо того, чтобы делать это, вы можете сказать, хорошо, ну, я в основном повторяю один и тот же шаблон несколько раз в этом цикле, почему бы мне просто не представить шаблон, иметь что-то намного меньшее, хорошо, хорошо, у меня может быть только один запись, сайт говорит, хорошо, хорошо, мой шаблон будет состоять из нескольких вложенных элементов div и элемента изображения. Ну, это все, что нужно, у меня не должно быть никаких исполнителей вокруг этого, у меня нет никакой дополнительной логики, если мне это не нужно, и вместо этого мы просто применяем шаблоны к этому поступающему каналу. через. В фреймворке мы фактически представляем, что фид — это либо модель, либо коллекция, и затем мы будем создавать шаблоны на основе этой коллекции, чтобы выводить их на экран, который является DOM, и это просто означает, что я могу фактически поддерживать шаблоны в несколько более читабельно, гораздо проще читать этот материал, чем проходить через все плюсы и минусы, которые у вас могут быть встроены, также легче, когда вы попадаете в точку, где вы можете захотеть управлять своим шаблоном за пределами вашей страницы , Таким образом, вместо того, чтобы поддерживать приложение, в котором вы должны иметь своего рода катонирование сценариев, а ваши различные шаблоны должны храниться встроенными, так что в более крупных приложениях вы увидите, что на самом деле есть большая выгода от выполнения этого вне вашей модели и ваших представлений. Если бы я хотел сказать, что у меня есть шаблон для представления того, как я на самом деле выводю элементы галереи, я могу просто сказать, вы знаете, item.tntl или item.txt, который может просто содержать представление разметки HTML для одного элемента на этом элементе. странице, одну фотографию на этой странице, а затем используйте ее с шаблонами для визуализации того, как будет выглядеть каждая другая фотография на странице. Это немного сложно объяснить, не показывая людям примеры, но, опять же, если вы посмотрите на новый MVC, то обнаружите, что на самом деле есть довольно много примеров того, как шаблоны могут эффективно использоваться с Фреймворки MVC и где это может пригодиться. Но да, я определенно рекомендую проверить это.

Луи: Да, абсолютно. Это то, что мы воспринимаем как само собой разумеющееся, работая на стороне сервера, но это, я думаю, все еще не является широко распространенной практикой, работающей на стороне клиента, возможно, потому что многие из этих фреймворков еще не получили широкого применения, но они определенно мощные и это определенно делает код более понятным, если, когда вам нужно изменить разметку, вы на самом деле изменяете разметку, а не копаетесь в коде, чтобы найти, о, я конкатенирую здесь div и хочу сделать это span сейчас; внезапно я должен пройти и найти все экземпляры кода, который делает это. Да, это звучит очень полезно, поэтому, я думаю, одна из проблем с Backbone заключается в том, что она довольно новая, она может показаться немного странной для людей, которые не привыкли работать с JavaScript в такой упорядоченной манере, люди используются просто щелкнуть скриптом, например, когда вы щелкаете по этой ссылке, что бы ни открывалось, или просто манипулированием DOM.

Адди: Хммм.

Луи: Так что это может иметь некоторую кривизну обучения, и я предполагаю, что именно в этом и заключается идея создания этой книги, верно?

Адди: Да, именно так. Так что я веду блог уже четыре или пять лет на JavaScript, и хотя блоги действительно полезны для начинающих, чтобы осваивать новые концепции и получать знания, они также идут с некоторыми оговорками, поэтому я решил написать эту книгу ; блоги содержат лишь ограниченное количество информации, которую вы можете передать в них, и я решил, зачем просто показывать кому-то, как создать приложение с каркасом, когда будут начинающие, которые спрашивают, где я могу изучить основы этой структуры, так что я могу использовать этот учебник. А потом у вас есть опытные пользователи, которые могут сказать, ну, это немного слишком для меня, я хотел бы знать, как я могу создать что-то более сложное, чем то, что вы мне сейчас показываете. И я думаю, что книга решает эту проблему довольно хорошо, потому что это означает, что если вы пришли из совершенно нового фона, и у вас очень мало опыта, такого как MVC в интерфейсе, или архитектурных шаблонов с JavaScript, вы можете просто прийти прочитайте книгу и начните с раздела «Основы», и вы довольно быстро освоите все эти понятия. Я начинаю довольно медленно, мы не бросаем людей в глубокий конец; Я думаю, что к концу первой главы вы поймете большую часть концепции, и одна из вещей, которую будет пытаться сделать книга, — это в первую очередь научить вас создавать очень простое приложение, а затем итерируйте это приложение, пока мы будем изучать оставшуюся часть книги, поэтому вы научитесь делать это приложение более сложным, научитесь интегрировать его с различными бэкэндами; есть люди, которые как бы просили узнать, как интегрировать Backbone с скажем Node.js или с Sinatra или с фреймворками WebSocket. И книга пытается помочь пользователю в их путешествии, поэтому она дает вам полный обзор — или мне, возможно, придется переделать это, но книга дает вам полный взгляд с высоты птичьего полета от начала до конца того, что вы Нужно научиться правильно использовать Backbone.