Загрузка 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. Но с другой стороны, если на сайт не добавляются новые модули, то эту работу достаточно выполнить всего один раз, в то время как преимущество в виде более быстрого открытия сайта, что ценят как пользователи, так и поисковые системы, будет постоянным.


0
Цитировать