Загрузка JavaScript по имени класса
В прошлом сообщении я рассказал о том, как сделать загрузку JavaScript и CSS полностью асинхронной на примере простого сайта всего с двумя файлами скриптов. На практике же гораздо чаще встречаются ситуации, когда на сайте используется несколько различных скриптов, причем они различаются для разных страниц сайта. Допустим, у нас есть сайт, на котором мы хотим показывать изображения в lightbox, страницы с формой комментария, для которых мы хотим показать WYSIWYG-редактор, и несколько форм, где нужно ввести дату. Рассмотрим несколько вариантов, как можно организовать загрузку скриптов.
Очевидно, что прописать загрузку сразу всех файлов скриптов и нужных для них — идея не самая удачная, (хотя есть CMS, в которых именно так и делается). Можно пойти другим путем: сделать в CMS массив, в который каждый модуль, используемый на странице, будет добавлять нужные ему файлы, а потом передать его в качестве параметра в основной скрипт MySite и загружать их из него (в частности, так я поступил в своей разработке TextCMS). Решение более приемлемое, но все же довольно громоздкое, особенно если делать загрузку асинхронной.
И, наконец, есть третий вариант, куда более простой в реализации: ввести соглашение, что всем элементам, для которых требуется тот или иной скрипт, будет прописываться класс с определенным именем. В частности, в нашем примере для фотогалереи (тега ul) будет прописан класс .gallery, для полей комментариев с WYSIWYG-редактором (тег textarea) будет прописан класс .wysiwyg, а для поля ввода даты (тег input) — класс .date. Теперь в основном скрипте сайта (файл mysite.js) можно с помощью jQuery сделать проверку наличия элементов с соответствующими классами, и загружать скрипты и стили к ним только в тех случаях, когда такие элементы найдены. Таким образом, на любой странице будут грузиться только те скрипты, которые действительно на ней нужны.
Вот пример кода, реализующего эту идею:
// загружаем Fancybox для эффекта lightbox
var lightbox_nodes = $('.lightbox');
if (lightbox_nodes.length) {
head.load(["/js/fancy/jquery.fancybox.css",'/js/fancy/jquery.fancybox.pack.js'], function() {
lightbox_nodes.attr('rel','attach').fancybox();
});
}
// загружаем WYSIWYG-редактор SCEditor
var wysiwyg_nodes=$('.wysiwyg');
if (wysiwyg_nodes.length>0) { // если массив с такими элементами не пуст
head.load(['/js/min/themes/default.min.css','/js/min/jquery.sceditor.min.js','/js/languages/ru.js'],function() {
wysiwyg_nodes.sceditor({
locale: "ru"
style: "/js/min/jquery.sceditor.default.min.css"
});
});
}
// загружаем Zebra date picker
var date_nodes = $('.date');
if (date_nodes.length) {
head.load(["/js/date/default.css",'/js/date/zebra_datepicker.js'], function() {
date_nodes.Zebra_DatePicker();
});
}
Недостаток такого подхода только один: отсутствие универсальности. Необходимо заранее знать все скрипты, которые требуются модулям сайта, и соответствующие классы, и прописать их в mysite.js. Но с другой стороны, если на сайт не добавляются новые модули, то эту работу достаточно выполнить всего один раз, в то время как преимущество в виде более быстрого открытия сайта, что ценят как пользователи, так и поисковые системы, будет постоянным.