Подключение внешних библиотек: jQuery, AngularJS и др.
Рассмотрим подключение часто используемых javascript-библиотек и фреймворков при разработке веб-приложений.
Для подключения любой из перечисленных библиотек, необходимо разместить указанный код перед закрывающим тегом </head>. В некоторых случаях, для увеличения скорости загрузки страницы, код размещается внизу страницы, до закрывающего тега </body>.
1. Подключение AngularJS
AngularJS — opensource javascript-фреймворк, предназначен для создания приложений использую шаблон MVC. Имеет богатую функциональность, позволяет работать с AJAX, DOM, анимациями, шаблонами и прочее. Главной особенностью является то, что он позволяет синхронизировать модель и представление, то есть позволяет динамически менять данные в интерфейсе при изменения данных в модели.
2. Подключение Angular Material
Angular Material — это одна из реализаций материального дизайна под Angular.
3. Подключение Dojo
Dojo — модульная javascript-библиотека, предназначена для упрощения разработки JS и AJAX приложений.
4. Подключение Hammer.JS
Hummer.JS — javascript-библиотека, предназначена для поддержки восприятия тактильного воздействия, проще говоря, улучшает взаимодействие с сенсорными экранами. Работает при поддержке jQuery.
5. Подключение jQuery
jQuery — популярная javascript-библиотека, основной задачей является взаимодействие JS и HTML. Имеет ряд возможностей для работы с DOM, обработкой событий, AJAX и визуальными эффектами. Для jQuery существует огромное количество дополнительных плагинов.
6. Подключение jQuery Mobile
jQuery Mobile — сенсорно-ориентированный фреймворк, предназначен для разработки веб-приложений с уклоном на планшеты и смартфоны.
7. Подключение jQuery UI
jQuery UI — javascript-библиотека, предназначена для создание пользовательского интерфейса. Имеет набор готовых виджетов.
8. Подключение MooTools
MooTools — объектно-ориентированный javascript-фреймворк, созданный для разработки веб-приложений. Протестирован во многих, в то числе и старых, браузерах.
9. Подключение SWFObject
SWFObject — js-скрипт, предназначенный для внедрения flash-роликов на страницы сайта.
Как подключить библиотеку к файлу формата .js
Требуется подключить библиотеки jquery, GMap.js в файл MyScript.js (Формальное название для примера). Дело в том что все эти скрипты в html документе выглядят не очень красиво и легко путаешься, хотелось бы вынести пару троек скриптов и подключать и подгружать их. Как это можно сделать?
Начнем с того, что именно подразумевается под «эти скрипты в html документе выглядят не очень» Если вы прямо вставляете текст скрипта — то это неправильный выбор, следует делать так:
Учитывайте, что загрузка скрипта останавливает основной поток, поэтому либо ставьте их в конце <body /> (но внутри) либо с параметром async .
Если же все-таки вы это знаете, но вам хочется динамически загружать скрипты из своего, то для этого можно либо воспользоваться библиотеками, например Require.JS или самому написать вот такое:
Есть еще один путь, т.к. у вас jQuery — ее можно использовать в качестве загрузчика — у нее есть такой функционал:
Т.к. у вас несколько скриптов, необходимо их загружать с учетом зависимостей.
import
Инструкция import используется для импорта ссылок на значения, экспортированные из внешнего модуля. Импортированные модули находятся в строгом режиме независимо от того, объявляете ли вы их как таковые или нет. Для работы инструкции во встроенных скриптах нужно прописать у тэга script type=»module» .
Существует также function-like динамический import() , который не требует скриптов с типом » module «.
Обратная совместимость может быть обеспечена с помощью атрибута nomodule тега script.
Динамический импорт полезен в ситуациях, когда вы хотите загрузить модуль условно или по требованию. Статическая форма предпочтительна для загрузки начальных зависимостей и может быть более полезна для инструментов статического анализа и tree shaking (en-US) .
Примечание: На данный момент эта функциональность только начинает поддерживаться браузерами. Полноценная реализация присутствует во многих транспайлерах, таких как TypeScript и Babel, а также в сборщиках, например, в Rollup и Webpack.
Синтаксис
Имя объекта, который будет ссылаться на значение экспорта по умолчанию (дефолтный экспорт) из модуля.
Имя модуля для импорта. Это зачастую относительный или абсолютный путь к .js файлу модуля без указания расширения .js . Некоторые сборщики могут разрешать или даже требовать использования расширения; проверяйте своё рабочее окружение. Допускаются только строки с одиночными или двойными кавычками.
Имя локального объекта, который будет использован как своего рода пространство имён, ссылающееся на импортируемые значения.
Имена значений, которые будут импортированы.
Имена, которые будут ссылаться на импортируемые значения.
Описание
Параметр name это имя локального объекта, который будет использован как своего рода пространство имён, ссылающееся на импортируемые значения. Параметры export определяют отдельные именованные значения, в то время как import * as name импортирует все значения. Примеры ниже объясняют синтаксис.
Импорт всего содержимого модуля
Этот код вставляет объект myModule в текущую область видимости, содержащую все экспортированные значения из модуля, находящегося в файле /modules/my-module.js .
В данном случае, доступ к импортируемым значениям можно осуществить с использованием имени модуля (в данном случае «myModule») в качестве пространства имён. Например, если импортируемый выше модуль включает в себя экспорт метода doAllTheAmazingThings() , вы можете вызвать его так:
Импорт единичного значения из модуля
Определённое ранее значение, названное myExport, которое было экспортировано из модуля my-module либо неявно (если модуль был экспортирован целиком), либо явно (с использованием инструкции export ), позволяет вставить myExport в текущую область видимости.
Импорт нескольких единичных значений
Этот код вставляет оба значения foo и bar в текущую область видимости.
Импорт значений с использованием более удобных имён
Вы можете переименовать значения, когда импортируете их. Например, этот код вставляет shortName в текущую область видимости.
Переименование нескольких значений в одном импорте
Код, который импортирует несколько значений из модуля, используя более удобные имена.
Импорт модуля для использования его побочного эффекта
Импорт всего модуля только для использования побочного эффекта от его вызова, не импортируя что-либо. Это запускает глобальный код модуля, но в действительности не импортирует никаких значений.
Импорт значения по умолчанию
Есть возможность задать дефолтный export (будь то объект, функция, класс или др.). Инструкция import затем может быть использована для импорта таких значений.
Простейшая версия прямого импорта значения по умолчанию:
Возможно также использование такого синтаксиса с другими вариантами из перечисленных выше (импорт пространства имён или именованный импорт). В таком случае, импорт значения по умолчанию должен быть определён первым. Для примера:
Импорт переменных
Если вы импортируете переменные, то в данной области видимости они ведут себя как константы.
Такой код выведет ошибку:
my-module.js
main.js
Для импорта можно воспользоваться объектом в котором хранятся эти переменные.
Такой код будет рабочим:
my-module.js
main.js
Учитывая, что import хранит именно ссылки на значения, экспортированные из внешнего модуля, то это можно использовать как замыкания.
Динамический импорт
Ключевое слово import можно использовать как функцию для динамического импорта модулей. Вызов import() возвращает Promise.
Как следствие возврата Promise, с динамическим импортом можно использовать ключевое слово await
Обратите внимание, что несмотря на то, что динамический импорт выглядит как вызов функции, он им по сути не является, т.е. не наследует от Function.prototype и, как следствие, его невозможно использовать вместе с методами .call , .apply и .bind
Примеры
Импорт из вспомогательного модуля для помощи в обработке запроса AJAX JSON.
Модуль: file.js
Основной код: main.js
Динамический импорт
Этот пример показывает, как можно загрузить на страницу дополнительный модуль в зависимости от действий пользователя (в данном случае, по клику на кнопку), а затем использовать функции из загруженного модуля. Промисы — это не единственный способ использовать динамический импорт. Функция import() также может использоваться совместно с await .
Модули JavaScript
Это третья публикация по материалам нашей внутренней конференции Sync.NET. Первая публикация была посвящена многопоточности в .NET, вторая — реактивным расширениям.
При разработке front-end части приложения на языке JavaScript, мы можем столкнуться с рядом традиционных проблем. Все они решаются при помощи модульных подходов. Ниже мы рассмотрим самые популярные подходы для описания модулей в JavaScript, которые существуют на сегодняшний день.
Итак, какие проблемы имеются в виду:
Большие файлы. Довольно часто возникает такая ситуация, когда в проекте есть файлы, названные в стиле app.js или common.js, в которых все просто свалено в одну кучу: функции, хелперы, виджеты и т.д. Работать и поддерживать код в таких файлах довольно тяжело. Приходится постоянно прокручивать туда-сюда, выискивая нужный кусочек кода, ставить много закладок при помощи IDE, чтобы не потерять нужные места в файле. Также есть тенденция, что чем больше размер файла, который содержит в себе кучу общей логики, тем быстрее он продолжает расти. Плюс ко всему, в большой команде это может стать причиной постоянных конфликтов в системе контроля версий.
Зависимости и порядок подключения. Зачастую JS-код в приложении разбит на несколько файлов. Мы используем плагины, которые зависят от библиотек; библиотеки, которые зависят от других библиотек; а код, написанный собственноручно, зависит уже и от того, и другого. Поэтому разработчик вынужден строго следить за порядком подключения JS-файлов и регулярно тратить время и энергию на их упорядочивание. Если нарушен порядок, то получаем ошибку. В любом случае, ошибки, которые возникают в связи с неправильным порядком подключения файлов, обычно достаточно легко заметить. В таком случае чаще всего мы просто получим исключение в браузере, например, $ is undefined .
Более трудной в обнаружении причиной ошибок может стать дублирование подключения одних и тех же файлов. Например, есть файл с куском кода, который вешает обработчик события на какой-либо dom-элемент. Ваш коллега может не заметить, что этот файл уже был подключен, и подключает его еще раз. В результате обработчик будет выполняться два раза, что может привести к неприятной ошибке, которую довольно трудно заметить сразу.
Переменные в глобальной области видимости. Проблемы с глобальными переменными заключаются в том, что они будут доступны во всем коде вашего приложения или страницы. Они находятся в глобальном пространстве имен, и всегда есть шанс возникновения коллизий именования, когда две разных части приложения определяют глобальные переменные с одинаковым именем, но для разных целей. Плюс ко всему, объявляя переменные в глобальной области видимости мы загрязняем объект window . И обращаясь каждый раз к глобальной переменной, интерпретатору JS приходится искать ее в раздутом объекте window , что сказывается на производительности кода.
Неструктурированный и не очевидный код. Еще одна довольно неприятная ситуация — когда нет четких границ, разделяющих логические куски кода. Когда, не вникая в код, сразу и не скажешь, какие другие части приложения он использует.
Первые модули
Изначально в JS не было возможности создавать настоящие модули. Хотя раньше это и не требовалось: на сайтах было относительно маленькое количество JS-кода. В основном нужно было где-то «прикрутить карусель», где-то красивое анимированное меню, и на этом все. Но затем web-приложения по сложности интерфейса и насыщенной функциональности начали догонять традиционные настольные. И тогда стал популярным так называемый паттерн «модуль».
Этот подход работает достаточно просто: создается немедленно-вызываемая анонимная функция-обертка, которая возвращает публичный интерфейс модуля, а вся остальная реализация инкапсулирована в замыкании. Это помогает решить две проблемы из вышеперечисленных: количество глобальных переменных сильно уменьшается, а сам код становится немного нагляднее благодаря тому, что мы разграничиваем его на логические куски. Но проблема управления зависимостями и порядком подключения файлов остается открытой.
CommonJS
Первый стандарт, который описывает API для создания и подключения модулей, был разработан рабочей группой CommonJS. Этот стандарт был придуман для использования в серверном JS, и его реализацию можно увидеть, например, в node.js.
Для подключения зависимостей используется глобальная функция require() , которая принимает первым параметром строку с путем к модулю. Для экспортирования интерфейса модуля мы используем свойство exports объекта module . И когда этот модуль будет подключен как зависимость с помощью функции require , где-то в коде другого модуля, то эта же функция вернет экспортируемый объект.
Данный подход решает все вышеперечисленные проблемы. Никаких оберток делать не нужно, каждый файл — это отдельный модуль со своей областью видимости. Исходный код можно разбивать на мелкие логические единицы. И каждый модуль четко определяет все свои зависимости.
НО! В браузере, просто так, такой синтаксис не заработает. Для этого нужно использовать специальный сборщик. Например, популярны browserify или Brunch, которые работают на node.js. Эти инструменты довольно удобны, их функциональность не ограничивается только лишь возможностью создавать CommonJS-модули, и многие разработчики предпочитают использовать их в своих проектах. Суть у них одинакова: сборщик проходится по дереву зависимостей модулей и собирает все в один файл, который в свою очередь будет загружаться браузером. Даже при разработке в debug-режиме нужно постоянно запускать сборщик из командной строки, или, что удобнее, запускать watcher, который будет следить за изменениями в файлах и автоматически производить сборку. Стоит заметить, что отлаживать приходится не исходные файлы, а то, что сгенерирует сборщик. Если вы не планирует отлаживать ваш код в старых браузерах, то это не будет проблемой, потому что сборщики умеют генерировать Source Maps, благодаря которым результирующий сжатый файл будет связан с исходниками. Это позволит вести отладку так, как будто вы работаете с самим исходным кодом. Также, сборка в один файл — это не всегда хорошо. Например, если мы хотим подгружать модуль удаленно, с CDN, или загружать часть кода только по требованию.
Будущее уже наступило
В новом стандарте ECMAScript 6, помимо всяких крутых штук, описан новый синтаксис для создания и подключения модулей.
Один модуль, как и в CommonJS, — это один файл. Область видимости также ограничена этим файлом. Ключевое слово export экспортирует нужные значения в остальные части программы. Его можно использовать где угодно: посреди кода модуля или в конце, экспортируя все скопом.
Для подключения модуля используются ключевые слова import , from и as . Можно импортировать только одно нужное вам значение…
…или сразу несколько.
Либо можно импортировать весь модуль в качестве объекта со всеми экспортированными значениями.
Есть возможность изменять имена переменных с импортируемыми значениями, что может быть полезным, если импортируются значения с одинаковым именем из разных модулей.
Для того, чтобы, например, отводить один файл под один класс, удобно определять экспортируемое значение по умолчанию.
Чтобы импортировать значение по умолчанию, достаточно лишь не использовать фигурные скобки.
В приведенных примерах использовался так называемый декларативный синтаксис. Также есть возможность использовать программный интерфейс, что позволяет загружать модули асинхронно и по условию. Для этого используется System.import() .
В качестве единственного параметра необходимо передавать путь к модулю. В результате выполнения System.import() возвращается объект Promise. Таким образом, поток выполнения не блокируется и код, который не имеет отношения к импорту модуля, будет выполняться дальше.
Браузеры еще толком не поддерживают новый синтаксис, но возможность использовать уже есть. В этом вам поможет один из специальных трансляторов, например, Babel. Как и в случае с CommonJS, нужно запускать транслятор из командной строки или ставить watcher, благодаря которому исходники, написанные на ES6, при изменении будут преобразовываться в кроссбраузерную форму.
Некоторые разработчики уже сейчас используют новый синтаксис, и точно можно сказать, что за этим подходом будущее. Большинство же не решаются пока использовать новую технологию в реальных проектах.
Вот уже несколько лет подход под названием Asynchronous Module Definition позволяет разбивать код приложений на модули во всех популярных браузерах (IE6+), используя при этом только возможности браузера.
AMD — это подход к разработке, который позволяет создавать модули таким образом, чтобы они и их зависимости могли быть загружены асинхронно и параллельно. Это позволяет ускорить загрузку страницы, так как загрузка JS-модулей не будет блокировать загрузку остального контента сайта. Плюс, AMD дает возможность загружать модули по мере их востребованности. Например, есть страница со сложным модальным окном, в котором сосредоточено много логики: разные «визарды», несколько форм и т.д. При этом предполагается, что окно будет использоваться крайне редко. В таком случае, AMD позволяет загружать JS-код для этого окна не со страницей, а перед тем, как оно будет открыто пользователем.
Проще говоря, подход AMD сводится к описанию модулей с помощью функции define и подключению их с помощью require .
Самая популярная реализация подхода AMD — библиотека RequireJS.
RequireJS
Скачать библиотеку можно с официального сайта, или же можно воспользоваться любым популярным пакетным менеджером. Например, с NuGet можно установить ее, выполнив команду Install-Package RequireJS.
В RequireJS методы require и define имеют несколько вариаций.
Метод define может принимать три параметра:
Первый параметр — это id модуля. id можно использовать вместо пути к файлу, чтобы подключить модуль как зависимость другого модуля, но только когда файл с кодом модуля уже был загружен в браузере. На самом деле, это необязательный параметр. И не просто необязательный, его даже нежелательно использовать в разработке. Он, скорее, нужен для корректного управления зависимостями в том случае, если в одном файле определено сразу несколько модулей. Оптимизационный инструмент, использующийся для сборки модулей в один файл для production, автоматически добавляет эти id.
define может принимать только остальные два параметра:
В данном случае первый параметр — это массив зависимостей модуля. Чтобы определить зависимость, нужно просто добавить в массив строку, содержащую путь к модулю или его id. Последний параметр — функция-фабрика, которая занимается созданием модуля. Эта функция выполнится только тогда, когда все зависимости модуля будут загружены, и принимает в качестве аргументов экспортированные значения со всех зависимостей. Внутри функции находится реализация модуля, которая не доступна извне. В конце с помощью вызова return экспортируется сам модуль. Экспортировать можно все, что угодно: обычную функцию, конструктор, объект, строку; в общем, любой тип данных. Важно понимать, что функция-фабрика выполняется только один раз, когда мы впервые подключаем модуль как зависимость. Остальные модули, которые тоже подключат эту зависимость, получат уже закешированное значение модуля.
Есть одна проблема — вызов define может выглядеть вот так:
Это довольно неудобно. Нужно следить, чтобы порядок указанных зависимостей в массиве совпадал с порядком аргументов, которые принимает функция-фабрика. Поэтому в RequireJS есть еще один вариант define , который позволяет передавать только один параметр — функцию-конструктор.
Этот вариант напоминает подход CommonJS. В качестве первого аргумента будет передана так называемая локальная функция require . Подключать зависимости модуля теперь можно с помощь вызова этой функции, а возвращать она будет те значения, которые экспортирует подключаемый модуль. Нужно помнить, что такой синтаксис функционально не отличается от предыдущего. Все файлы зависимостей, подключенные с помощью вызова require , будут загружены до того, как начнет выполнятся функция-фабрика модуля. Это происходит потому, что, когда файл модуля загружен в браузер, загрузчик ищет все локальные вызовы require с помощью регулярных выражений. По этой причине локальный вызов require нельзя использовать, например, для загрузки модуля по условию.
Также можно определить модуль как простой объект.
Такие модули удобно использовать как набор констант.
Для того, чтобы начать выполнение клиентской логики, нужно вызвать глобальную функцию require .
Этот вариант функции require отличается от локального варианта набором принимаемых параметров. В этом случае первым параметром нужно передавать массив подключаемых модулей. Даже если нужно подключить только один модуль, все равно нужно передавать его в массиве, иначе библиотека распознает его как локальный вызов и будет ошибка, так как локальные вызовы возможны только внутри определения модуля. Второй необязательный параметр — callback-функция, которая, как и в случае с define , выполнится сразу, как только будут загружены все необходимые зависимости.
Есть возможность делать вложенные вызовы require внутри callback-функции или внутри определения модуля.
Еще одно существенное отличие такого варианта вызова require заключается в том, что подключаемые файлы начнут загружаться только тогда, когда поток выполнения дойдет до вызова функции. Благодаря этому есть возможность загружать модули только по требованию или по условию.
Подключение
Для работы понадобится всего один единственный тег
Указанный в data-main атрибуте файл main.js (расширение .js для краткости в RequireJS всегда опускается) является своеобразной точкой входа для выполнения JS-кода приложения.
RequireJS имеет ряд параметров, которыми можно его сконфигурировать, поэтому перед началом выполнения кода они должны быть указаны с помощью метода requirejs.config .
При помощи первого параметра baseUrl можно указать путь, относительно которого будут загружаться все JS-файлы. Если файлы вдруг переедут в другое место, то достаточно в одном месте поменять корневой путь. Если его не указать, то базовой будет директория, в которой находится файл самой библиотеки require.js. Параметр path позволяет «мапить» пути к модулям, чтобы использовать потом более короткие варианты.
Многие сторонние библиотеки и плагины уже оформлены в стиле AMD, то есть определены как модули с помощью функции define . Но есть такие, которые еще так не оформлены. Подключая подобные файлы, RequireJS не знает об их зависимостях и экспортируемом значении. Для таких модулей есть параметр shim , благодаря которому можно указать deps (зависимости) и exports (экспортируемое значение).
RequireJS позволяет загружать не только JS-файлы, но и, например, HTML, используя плагин text.
В данном примере require загрузит файл module.html и вернет строку, содержащую HTML-код файла. Это удобно для работы с клиентскими шаблонами, не нужно мучатся с HTML-кодом внутри JS-файлов.
Сборка
Загружать много мелких файлов удобно при разработке и отладке, но не очень производительно, поэтому не подходит для production. И тут на помощь приходит утилита оптимизации r.js, которая идет в поставке с require.js.
Работает эта утилита на JS, поэтому на компьютере должен быть установлен node.js. Перед тем как запускать оптимизацию, нужно ее сконфигурировать. Для этого в приложении нужно создать файл app.build.js, который будет содержать обычный JS-объект с набором параметров.
Параметр baseUrl назначается так же, как описывалось выше. dir — директория для результирующего файла. main — путь к файлу, который содержит конфигурацию RequireJS. preserveLicenseComments — удалить комментарии о лицензиях, wrapShim — обернуть все shim-модули функцией define . Остальные возможные параметры можно посмотреть здесь: example.build.js.
Запустить сборку можно командой >node r.js -o app.build.js
Будет удобно добавить эту команду, например, в pre-build event в Visual Studio, чтобы JS-код собирался в тот же момент, когда запускается компиляция проекта.