Я уже писал в одной из заметок о шаблонах на JS. В этот раз я рассмотрю диаметральный подход – компилируемые шаблоны. Примерами таких шаблонов могут служить mustache.js, Underscore template и многие другие библиотеки.
В их основе лежит один и тот же принцип: конструктору передается исходный шаблон в виде строки текста; на выходе получаем некую функцию. Эта функция, в свою очередь, возвращает строку, в которой вместо размеченных особым образом фрагментов будут подставляться аргументы, использованные при вызове. Так же в шаблонах может быть реализована простая логика ветвления, циклы или вызов вспомогательных функций.
Интересным аспектом применения компилируемых шаблонов является то, где и как будет храниться исходный текст шаблона и скомпилированный шаблон. На ум приходят несколько вариантов:
- в виде строки в js-файле;
- внутри тега
<script>
с произвольным типом в html; - в отдельном файле;
- компилирование исходного текста шаблона при сборке проекта.
Хранение в js-файле
var templateSource = "<div class=\"welcome\">" +
'<p class="welcome__message">Hello: <%= name %></p>' +
'</div>';
var template = _.template(templateSource);
Плюсы:
- исходный текст шаблонов конкретного модуля сразу доступен для компиляции в момент инициализации этого модуля;
- с большой вероятностью файл, содержащий шаблон, будет закеширован браузером, что в общем счёте сэкономит трафик при регулярном посещении страницы.
Минусы:
- текст шаблона перемежается с логикой;
- содержимое строки в JS нужно правильно экранировать;
- для разных ролей пользователей могут понадобиться разные шаблоны, а это, в свою очередь, может скомпрометировать какую-то часть функциональности пользователей с высоким уровнем доступа.
Хранение в исходном HTML-коде страницы
<script id="template-welcome" type="text/x-template">
<div class="welcome">
<p class="welcome__message">Hello: <%= name %></p>
</div>
</script>
Браузер содержимое тега <script>
считает простым текстом, а так как в атрибуте type
у него указан неизвестный ему MIME-тип, то интерпретировать или отображать он его не станет. Зато содержимое этого тега можно получить после загрузки документа, обратившись к нему по id
.
var templateSource = document.getElementById("template-welcome").innerText;
Плюсы:
- размещается вместе с другой разметкой;
- набор шаблонов или их содержимое может динамически меняться в зависимости от внешних факторов.
Минусы:
- если страница не будет закеширована браузером, то эти шаблоны будут каждый раз загружаться с сервера;
- возможно, потребуется подождать окончания загрузки страницы, прежде чем к элементу, содержащему исходный текст шаблона, можно будет получить доступ.
Хранение в отдельном файле
Шаблоны, ко всему прочему, можно хранить в виде отдельных статических или генерируемых динамически файлов и загружать при необходимости.
<?xml version="1.0" encoding="UTF-8"?>
<templates>
<template id="template-welcome"><![CDATA[
<div class="welcome">
<p class="welcome__message">Hello: <%= name %></p>
</div>
]]></template>
<template id="template-product"><![CDATA[
…
]]></template>
</templates>
Текст шаблона обязательно должен быть заключен в блок CDATA
, чтобы его содержимое можно было получить без изменений.
$.ajax("/static/templates/welcome.xml")
.done(function (templates) {
var templateEle = templates.getElementById("template-welcome");
if (templateEle) {
callback(_.template(templateEle.innerText));
}
templateEle = null;
});
Набор шаблонов загружается с помощью XHR, а затем методом getElementById()
получаем нужный объект, содержащий исходный текст шаблона.
Плюсы:
- с большой вероятностью статический файл, подгружаемый через XHR, будет закеширован браузером, и в дальнейшем некоторое время не будет запрашиваться с сервера;
- можно организовать дополнительный уровень кеширования шаблонов (Local Storage, например);
- наборы шаблонов можно формировать для конкретной комбинации ролей пользователя, что позволит защитить функциональность недоступную текущему пользователю.
Минусы
- дополнительный HTTP-запрос при первом посещении;
- инициализация модуля будет «отложенной» из-за асинхронной загрузки требуемых шаблонов.
Компилирование при сборке
В твиттере и комментариях мне подсказали ещё один способ хранения шаблонов. Каждый шаблон хранится в виде HTML-файла, а на этапе сборки эти файлы компилируются в js-функции и сериализуются прямо на сервере. В итоге клиент будет загружать обычные статические js-файлы.
Плюсы:
- шаблоны будут кешироваться браузером как любые другие статические ресурсы;
- браузер не тратит время на компиляцию шаблона.
Минусы:
- для работы нужен процесс сборки проекта;
- для компилирования шаблонов при сборке потребуется соответствующая технология (Node.js или нативная реализация на соответствующем языке программирования), что может быть накладно.
Заключение
Метод хранения сложных шаблонов в отдельных статических файлах мне кажется достаточно перспективным по сравнению с хранением тех же данных в HTML. С другой стороны, инициализация модуля оказывается гораздо сложнее, чем в случае с хранением шаблона в JS. Компилирование шаблона при сборке может стать идеальным вариантом, если в проекте есть сборка как таковая.
Мастер-класс по Backbone.js
Для своих коллег я устроил вводную лекцию по Backbone.js и провёл мастер-класс, написав простое интерактивное приложение.
Для запуска серверной части приложения понадобиться Node.js. После распаковки архива нужно будет загрузить все требуемые зависимости с помощью менеджера пакетов:
npm install
Сервер запускается командой
node app.js
Самое приложение будет доступно по адресу http://127.0.0.1:3000/
Если у вас появятся какие-либо вопросы по этому мастер-классу, то не стесняйтесь задавать их в комментариях или мне в почту.
Использование setTimeout() вместо setInterval()
Функция setInterval()
предназначена для вызова переданного ей колбека через равные промежутки времени. У неё есть две особенности:
- Сложно (а иногда попросту не возможно) заниматься отладкой такого кода из-за того, что вызовы колбека будут производиться независимо от того, в каком месте кода вы поставили точку останова. На каждый шаг отладки управление будет передаваться основному циклу, который исправно вызовет колбек о очередной раз.
- Если длительность выполнения колбека по каким-либо причинам превысит установленную задержку, то это автоматически приведёт к лавинообразному увеличению количества замыканий, «выполняемых одновременно». Колбек будет вызываться снова и снова через заданный промежуток времени, не дожидаясь завершения предыдущего вызова.
От этих проблем можно избавиться, если воспользоваться setTimeout()
. В этом случае планирование следующего вызова будет производиться только после завершения выполнения предыдущего.
/**
* @param {Function} callback
* @param {Number} delay
* @param {Object} [context]
* @return {Function}
*/
function interval(callback, delay, context) {
var start = new Date(), id;
delay = delay || 0;
context = context || this;
(function loop() {
var result = callback.call(context, new Date() - start);
if (result !== false) {
id = setTimeout(loop, delay);
}
}());
return function () {
if (id) {
clearTimeout(id);
id = 0;
}
};
}
Кроме того, мы получаем несколько способов завершить выполнение этого бесконечного цикла. interval()
возвращает функцию, с помощью которой можно прерывать следующий запланированный вызов колбека. Если колбек сам вернет значение false
, то выполнение цикла также прекратится.
function doStuff(time) {
$("body").append("<p>" + time + "</p>");
return time < 10000;
}
var cancelFn = interval(doStuff, 1000);
$("button").on("click", cancelFn);
При очередном выполнении колбека, ему в качестве параметра передается разница между текущим временем и временем вызова функции interval()
. Так легко можно синхронизироваться по времени. Ведь теперь нет гарантий того, что пятый вызов колбека будет произведен ровно через 4 секунды.
Создание списка изменений из Git
Список всех коммитов от указанного объекта до HEAD
можно легко получить с помощью команды
git log 1ff893.. --pretty=format:%s --no-merges > changes.txt
В файл changes.txt
будут записаны только названия комитов, начиная с 1ff893 и до текущего состояния, за исключением точек слияния. В качестве начального объекта можно указать название тега или ветви.
В случае ветвления, обход дерева будет выполнен так, что в отчёт попадут все коммиты, которые не были предками для стартового объекта. Что само по себе достаточно удобно из-за того, что формально они могут быть старше, но объединены гораздо позже.
Если, например, попытаться получить лог от S до F, то в файл буду записаны коммиты с номерами от 1 до 8. Коммиты M — это точки слияния, которые сами по себе не несут никакой новой функциональности, не будут включены в лог.
Дополнение
- Порядок коммитов можно изменить ключом
--reverse
- Варианты форматирования
Отчёт о поездке на конференцию Fronteers
4 и 5 октября 2012 года в Амстердаме проходила ежегодная международная конференция для веб-разработчиков Fronteers и мне удалось побывать на ней.
В нашей компании после поездки принято делать краткие отчёты-презентации. Для такого отчёта я подготовил слайды с тезисами и ссылками на презентации докладчиков.