Пишем свой JavaScript шаблонизатор. Обзор актуальных шаблонизаторов JS Примерный вид parseStar()

Есть несколько случаев, когда вам может понадобиться шаблонизатор на JavaScript , среди них как необходимость формирования содержимого на клиенте, так и на сервере, если используется JavaScript среды, такие как NodeJS или Rhino . Сразу скажу, что для себя рассматривал многие имеющиеся шаблонизаторы, от простых до экзотических. Более всего интересовали простые, однако позволяющие использовать сложную логику в шаблонах, и одним из таковых оказался EJS . Однако, штука эта была написана несколько не так, как мне бы хотелось, с одной стороны было много лишнего, с другой основная функциональность уж слишком усложнена. Я увидел возможность реализовать компиляцию и рендеринг его шаблонов гораздо проще.

Применение EJS

То, что делает шаблонизатор : беря шаблон и данные , возвращает экземпляр содержимого , полученный путём обработки шаблона на основе этого конкретного экземпляра данных .

В случае EJS суть проста: в составе шаблона мы можем совмещать выводимое как есть содержимое с кусочками встроенного JavaScript , аналогично тому, как в файлах сценариев PHP объединяется HTML с кодом. В коде видны как глобальные переменные, так и те, что мы позаботимся передать рендереру при вызове. Ещё там видны так называемые функции-помощники, которые упрощают формирование часто используемых конструкций, например, тегов ссылок или картинок.

Код обрамляется в тег <% ваш код для исполнения %> или в тег <%= ваша переменная для вывода %> .

Вот как это может выглядеть:

<%if(content){%> <% if (title) { %>

<%=title%>

Я намеренно написал конструкции в разных стилях, чтобы показать, что наличие пробелов значения не имеет. Формируя вывод с использованием шаблона, мы передаём объект со свойствами, выступающими в качестве переменных, с которыми оперирует код внутри нашего шаблона. Смысл в том, что с помощью логических конструкций на самом же JavaScript можно гибко менять вид формируемого в результате содержимого. Как вариант возможно использование тегов вида [% %] , если шаблон предполагается рендерить уже после того, как он включён в дерево DOM . В свете моих паттернов использования, оно мне показалось не очень полезным.

Улучшаем EJS

В оригинальном шаблонизаторе меня не устроил лишний функционал обслуживающий загрузку шаблонов из файлов, который мне в принципе был не нужен, поскольку предполагалось его использование в серверных средах, не только на стороне клиента. Также неприятно удивила сложность самого компилятора, поскольку я предпочитаю использование нативных вызовов сложности логики кода. По этим причинам решил таки написать компилятор с нуля, о чём мы далее и поговорим.

Разбор исходных шаблонов

Компиляция всегда начинается собственно с разбора исходного материала по заведомо заданным правилам. Наш набор правил сводится к различению содержимого в специальных тегах и всего остального. Глядя на структуру наших специальных тегов, можно понять, что достаточно просто захватывать их целиком с помощью несложного регулярного выражения. Помним, что кроме собственно кода, нам понадобится вытаскивать открывающий тег, чтобы понять, что делать с кодом внутри. Вот как будет выглядеть RegExp:

/(?:\n\s*)?(<%[=]?)((?:[^%]|[%][^>])+)%>/gm

Итак, что мы здесь делаем:

• (?:\n\s*)? - убираем перевод строки и все пробелы от него до тега кода, если таковое вообще присутствует. Это, конечно, делать было вовсе не обязательно, но мы же эстеты, так предотвратим появление множества пустых строк в формируемом содержимом. Спецификатор ?: в начале подпаттерна означает, что его содержимое не захватывается, а просто пропускается.
• (<%[=]?) - захватываем собственно открывающий тег. На этот раз захватываем целиком подпаттерн открывающего тега, что нам потребуется потом при формировании кода.
• [^%]|[%][^>] - наш код - это любые символы, не являющиеся % , или символ % , за которым не следует символ > .
• (?:[^%]|[%][^>])+ - наш код - эти последовательности могут присутствовать более одного раза, но не должны захватываться.
• ((?:[^%]|[%][^>])+) - наш код - а захватываем мы всю последовательность целиком.
• %> - закрывающий тег не захватываем.
• gm - включаем глобальную полнотекстовую (многострочную) обработку.

Как можно видеть, всё достаточно тривиально, осталось разобраться, что делать с этим регулярным выражением. А здесь нам поможет очень полезный метод String.split , который разбивает строку с использованием указанного разделителя, возвращая массив получившихся подстрок. Особенность данного метода в том, что в качестве разделителя он может принимать регулярное выражение, причём, если в нём присутствуют захватываемые подпаттерны, подстроки, которые им соответствуют, также попадут в результирующий массив в обычном порядке. Это и даёт нам идею нативной оптимизации компилятора шаблонов: разбиваем строку регулярным выражением, получаем последовательность из кусочков строчного контента и спецификаторов кода со следующими за ними кусочками этого кода, далее достаточно просто обработать получившийся массив.

Формирование исполняемого кода

Теперь у нас имеется разобранный шаблон, а значит уже можно представить, каким образом вполне линейно преобразовывать его в исполняемый код на JavaScript. Всё, что нам нужно, это получить функцию, вызывая которую, мы будем получать корректно сформированное согласно исходному шаблону содержимое. Так, куски содержимого из шаблона должны вставляться как есть, на место переменных должны вставляться их значения, а код должен выполняться.

Организуем это следующим нехитрым образом:

• функцию будем формировать в виде строки, пригодной для вызова eval
• в теле функции организуем последовательное присоединение кусочков содержимого к некой переменной результата
• обычный код на JS вставим как есть

Однако нам потребуется решить следующие проблемы:

• передача переменных и функций-помощников в тело исполняемой функции шаблона
• организация переменной результата так, чтобы это не пересекалось с переменными, используемыми в шаблоне

Решение первой проблемы

Для того, чтобы решить первую проблему, проще всего использовать конструкцию with . Да, это именно та вещь, которая является извечной темой бурных дискуссий разработчиков и головной болью стандартизаторов w3c, именно её так ненавидят всякие валидаторы типа JSLINT и компиляторы вроде Closure Compiler . То, что делает данная конструкция, проще всего представить как предоставление объекта в качестве уровня видимости локальных переменных, то есть вы сможете обратиться к свойствам объекта по имени как к обычным переменным, то есть без префикса имени объекта с точкой, вот, как это выглядит:

Var obj = { foo: "It is foo.", bar: 42 }; with(obj){ foo += " And bar is " + bar; }

При чтении значений всё довольно просто, не так тривиально при записи, особенно при использовании вложенных конструкций with , однако в шаблонах нам потребуется в основном читать значения, поэтому использование нативного подхода вместо того, чтобы городить очередной костыль, более чем оправданно. Если быть точным, то на самом деле создаются два взаимовложенных уровня видимости локальных переменных: один из объекта, другой внутри тела with, то есть при создании локальных переменных там, они не попадают в исходный объект.

Решение второй проблемы

Осталось придумать, как мы будем собирать кусочки содержимого в функции рендеринга шаблона. Первое, что может прийти в голову, просто создать локальную переменную в теле функции с редко встречающимся именем и присоединять к ней всё, что нужно по ходу выполнения. Признаться, в начале я так и хотел поступить, это весьма неплохая идея, если свести вероятность пересечения имени переменной к минимуму. Однако, что и говорить, данное решение весьма не эстетично, как творцы высокого искусства, мы не имеем права создавать вообще никакие локальные переменные в этой непорочной функции.

Посмотрим, что у нас есть, а вариантов в общем то не много: как-то использовать объект this или объект arguments , которые, ввиду особенностей языка, пользователь всё равно не должен использовать в шаблонах, а если и может, то лишь неким особым образом. Рассмотрев все за и против, я решил использовать arguments , массив неименованных аргументов, переданных функции, в один из них и будем класть всё, что нужно для корректного формирования содержимого.

Особенности реализации

Теперь у нас есть всё, чтобы реализовать законченный движок шаблонизатора. Как я уже говорил, он не будет полностью совместим с оригинальным EJS, однако сможет использовать созданные для него шаблоны. Также не будет реализации автоматического загрузчика шаблонов, его нужно прикрутить самостоятельно, опираясь на принципы используемого вами фреймворка в данной конкретной среде исполнения.

Самое время перейти непосредственно к коду, рассмотрим всё по частям, начиная с главного и основного, а именно, с объекта шаблона:

// Конструктор var EJS = function(src){ if(typeof src == "string"){ // Если передан шаблон this.compile(src); // Сразу компилируем его } }; // Прототип EJS.prototype = { regexp: /(?:\n\s*)?(<%[=]?)((?:[^%]|[%][^>])+)%>/gm, helper: {} // Функции-помощники };

EJS.prototype.compile = function(src){ delete this.method; delete this.error; // удаляем следы предыдущего вызова компилятора var p = src.split(this.regexp), // Результат разбора r = , // Результат сборки i, o; this.parsed = p; // Сразу же сохраняем результат разбора // Выполняем сборку функции генерации содержимого for(i = 0; i < p.length; i++){ if(p[i] == "<%"){ // Если встречаем просто код o = p[++i]; // Вставляем, как есть }else{ // В противном случае, имеем дело с содержимым if(p[i] == "<%="){ // Если это переменная шаблона, o = p[++i]; // просто выводим её }else{ // Если это кусочек самого шаблона, o = "arguments[" + i + "]"; // будем брать его из результата разбора } o = "arguments+=" + o + ";"; // Формируем конструкцию для вывода } r.push(o); // Добавляем полученную часть кода к результату } // Вставляем начало и конец функции генерации содержимого r.unshift("this.method=function(){"+ "with(arguments){"+ "with(arguments){"); r.push("};};return arguments;};"); try{ // Пробуем вычислить полученный код, собрав в строку eval(r.join("\n")); return true; // Возвращаем истину }catch(e){ // Если что-то пошло не так, формируем ошибку if(typeof this.check == "function"){ // Если доступно, // выполняем продвинутое обнаружение ошибок // (например, с помощью JSLINT) e = this.check(r); } this.error = new EJS.CompileError(e.message); return this.error; // Возвращаем ошибку } };

Осталось добавить функцию рендеринга шаблона, но она более чем тривиальна:

EJS.prototype.render = function(data){ // Принимаем единственный аргумент, объект с переменными шаблона if(this.method instanceof Function){ // Если есть скомпилированный шаблон try{ // Пробуем применить шаблон return this.method("", this.parsed, this.helper, data); // Если получилось, возвращаем сформированное содержимое }catch(e){ // Если ничего не получилось, формируем ошибку рендеринга this.error = new EJS.RenderError(e.message); } } return this.error; // Возвращаем ошибку };

Конечно, не забываем добавить функции ошибок:

EJS.CompileError = function(message){ if(typeof message == "string"){ this.message = message; } }; EJS.CompileError.prototype = new Error(); EJS.CompileError.prototype.name = "EJS.CompileError"; EJS.RenderError = function(message){ if(typeof message == "string"){ this.message = message; } }; EJS.RenderError.prototype = new Error(); EJS.RenderError.prototype.name = "EJS.RenderError";

Ну и если хотим, добавим функции-помощники:

// Функция для красивой работы с функциями-помощниками EJS.Helper = function(name, func){ // Не трудно догадаться, как её использовать для // получения, добавления и удаления функций-помощников if(arguments.length < 2){ return EJS.prototype.helper; } if(func === null){ delete EJS.prototype.helper; return; } if(typeof func == "function"){ EJS.prototype.helper = func; return true; } }; EJS.Helper("img_tag", function(src, alt){ // Тэг картинки return src ? "" : ""; }); EJS.Helper("link_to", function(title, href){ // Тэг ссылки return title && href ? "" + title + "" : ""; }); // Далее добавьте свои

На этом почти всё, ну разве только что могу предложить сделать более высокоуровневую обёртку вокруг всего этого.

Что дальше?

Ну и собственно, предлагаю эту самую высокоуровневую реализацию. Если вас устраивает то, что уже есть, дальше на тему читать не обязательно, потому что далее будет только хуже будет рассмотрена реальная жизнь.

В моих проектах применяется такая штука как RequireJS , которая реализует единый механизм связывания кода ваших приложений, да и не только кода, а вообще в принципе любых типов ресурсов, причём независимо от среды, в которой выполняется ваш код на JavaScript. В статье я уже писал о том, как это работает, однако одна очень полезная особенность так и не была рассмотрена. Это использование и разработка так называемых плагинов RequireJS. Но данный вопрос будет темой следующей статьи, эта итак получилась весьма не маленькая.

Здесь выкладываю библиотеку с некоторыми тестами, для запуска которых на стороне сервера вам понадобится NodeJS с установленным RequireJS , а на клиентской стороне web-сервер nginx . Тестируется командой make из директории проекта.

Число JS-библиотек ни в коей мере не уменьшается; наоборот, оно растёт с каждым днём. Когда мы доходим до приложений JS, лучшим выбором оказываются шаблоны, чем полноценные библиотеки, потому что это приводит к более чистому базовому коду и лучшему процессу работы с ними .

Не так давно я писал, что вы могли бы попробовать написать свою библиотеку , когда придёт время. Шаблонизаторы же требуют несколько больших навыков и понимания языка, с которым вы работаете, поэтому лучше полагаться на любой шаблонизатор из имеющихся в списке ниже.



Их список можно найти в Википедии , там отлично сравниваются движки для разных языков программирования для веба, но там действительно не фокусируются на одном языке, поэтому я хотел бы посмотреть, как много движков можно перечислить для Javascript.

Если вы разрабатываете на Javascript, то узнаете ряд движков, но можно узнать и о некоторых новых. Я с удовольствием продолжу этот список вместе, и надеюсь, что он вас порадует.

chibi.js

Chibi даёт всё для экономии траффика и времени для отображения шаблона, небольшая и лёгкая библиотека, которая поможет лучше шаблонизировать приложение. Больше фокусируется на CSS вместо использования анимации. (Дословная «вода» автора - перев.)

templayed.js

Это - самый маленький шаблонизатор, с которым вы столкнётесь, гарантированно (Nano - перев.) . Он построен на основе Mustache, прост в использовании и понимании. Сайт имеет большой демо-пример, в котором можно запускать и тестировать код.

ECT

Подобно templayed, ECT тоже имеет демо-страницы установки на сайте, с которыми можно «поиграться» и понаблюдать живые результаты. Он сделан для скорости, и заявляет о себе как о самом быстром шаблонизаторе для JS (построен на Coffeescript). Совместим с Node.js и имеет понятный синтаксис. На Github есть бенчмарки и модульные тесты , показывающие эффективность этой библиотеки.

Pithy.js

Имеется внутренний DSL для генерации HTML в JavaScript. Это отлично для небольших фронтенд-проектов, но не рекомендуется для тяжёлых HTML-страниц.

T.js

T.js использует простую структуру данных Javascript для представления данных HTML / XML.

Nunjucks

Созданный в Mozilla, Nunjucks сделан для нуждающихся в производительности и гибкости из-за возможности расширять пользовательскую библиотеку плагинов и функций.

Jade

Jade рассчитан прежде всего для серверных шаблонов в node.js, но может работать во многих других средах. Он сделан только для XML-подобных документов (HTML, RSS, ...), поэтому не используйте его для оформления простого текста, markdown, CSS и подобных документов.

Dust.js

Dust расширяет Mustache и предлагает высокое качество исполнения по сравнению с другими решениями из этого списка. Содержит очень простой и понятный API.

Движки шаблонизации Javascript

Надеюсь, что вы смогли открыть для себя новые варианты для вашего следующего проекта. Уверен, что много альтернатив не упомянуто, но использование перечисленных ощущается больше всего.

UPD : комментаторы статьи-оригинала добавили :

• "Pure - Simple and ultra-fast templating tool to generate HTML from JSON data
• Dust.js is used by PayPal, and default in their Kraken.js framework.
• Swig - A simple, powerful, and extendable JavaScript Template Engine.

• Twig - JS implementation of the Twig Templating Language
• EJS Embedded JavaScript templates for node

Но так как я частенько увлекаюсь JavaScript"ом, то решено было найти подобный шаблонизатор для этого языка, но серверного (node.js, ага). Первые ссылки в поисковике выдают такие шаблонизаторы, как: ECT , JUST , . Все они, естественно, не подходили для меня, т.к. слишком далеко были от синтаксиса Smarty.

Чтож, раз хочется, а решений нет - то сделай. Выискивая время на работе и иногда получая по «шапке», родился проект NodeSmarty , который, в будущем, будет частично копировать синтаксис Smarty .

Итак, свои корни проект пустил примерно 4 месяца назад, в сентябре 2012 года и постепенно обретал рабочий вид. По началу весь алгоритм компиляции шаблонов брался из Smarty (файл Smarty_Compiler.class.php), некоторые функции не были перенесены. В процессе написания кода я делал всевозможные сокращения кода в плане простоты, так как это «мой стиль». Поэтому были заменены все огромные регулярные выражения (да и в них, кстати, всё равно было полно ненужного мусора), часть логики в функциях.

Так как проект необкатанный, то совершенно понятно, что в процессе будет найдено достаточное количество багов. Также уверен, что будут жалобы в сторону обработок ошибок в шаблонах (на данном этапе эта «функция» реализована плохо). Я буду только рад получать сообщения об улучшении кода, и по мере своих возможностей вносить как исправления, так и новые функции.

Примеры работы шаблонизатора:

compiler.js:
var NodeSmarty = require("./NodeSmarty/"); var Template = new NodeSmarty(); Template .setTemplateDir("./templates/") .setCompileDir("./compile/") .setCacheDir("./cache/"); var Array = ["val1", "two"]; Template.assign({ "Value":"first", "number":10, "array":Array }); var Final = Template.fetch("template.tpl", function(data) { console.log(data); });

template.tpl:
{include file="header.tpl.html"} {$Value} {$number*10/20} {if !$Value} //... {elseif $number = $Value} //... {else} //... {/if} {* comment *} {literal} for(var di=0; di < 10; di++) { console.log(di); } {/literal} {foreach from=$array item=Foo key=Key} Item: {$Foo} key: {$Key} {/foreach}

Скорость выполнения кода выше, чем у EJS и JUST. Происходит это из-за того, что при повторном запросе файла, вызывается не шаблон, а уже скомпилированный код. Но есть и еще один плюс (хотя его и нет, но будет в будущем) - повышение скорости выполнения также зависит от файловой системы (дада, сначала нужно проверить, не изменились ли шаблоны, перекомпилировать их). Если же компилировать файлы при первом запросе, а при последующих просто выгружать из памяти, то скорость соответственно увеличится, и время выполнения кода станет еще меньше!

Сравнение скорости выполнения кода при 1000 итераций:

Немножко о принципе работы.

Если шаблон изменен раньше, чем скомпилирован файл, то библиотека просто подгружает скомпилированный файл и подставляет в него значения. Если же шаблон изменен позже, то выполяются следующие инструкции:

Первым делом парсится документ на наличие открывающего тега: { и закрывающего тега: } (хотя можно и изменить по желанию, см документацию).
Потом каждый тег парсится на главный параметр и атрибуты. Главный параметр также проходит обработку и разбивается на 2 типа: команда или переменная. Переменная отличается от команды впередистоящим знаком доллара ($ ). И переменная и команда проходят обработку для преобразования себя в рабочий JavaScript код. Скомпилированный код записывается в файл и происходит eval текста (хотя там не eval, а new Function() ).

Фреймворки шаблонизаторы отделяют макет (разметку страницы) динамических веб-сайтов и приложений от интегрированной в них логики. Все фреймворки поддерживают различные формы циклов, условной логики и специального форматирования. Но мне хотелось получить такой движок, который бы располагал продвинутыми инструментами построения страницы для нескольких целей:

• для совместного использования разметки на страницах;
• для включения отдельных блоков с функциональностью (при необходимости);
• в общем и целом для упрощения процесса построения в меру сложных макетов страниц c минимумом прилагаемых усилий.

Сравнение шаблонизаторов

Существует ряд популярных шаблонизаторов для JavaScript, и мы рассмотрим некоторые из них:

EJS

EJS (Встроенный JavaScript) очень напоминает PHP или JSP, очень простые функции – слишком простые для того, чтобы быть хоть в чем-то полезными. Сразу исключаем.

Jade

Наиболее характерной особенностью Jade является то, что он обозначает пробел без кавычек (как Coffeescript),что или является чудом (если вы верите в подобные вещи), или катастрофической неисправностью, если вы реалист (как я). По своим характеристикам этот шаблонизатор стоит на одном уровне с большинством других систем, но его стилевое оформление заставляет нас почти сразу его отбросить.

Mustache / Handlebars

Использует знакомую { { систему токенов } } для встраивания логики в существующие шаблоны (и не только HTML). Обеспечивает хороший набор циклов, логику и управление переменными. Не очень хорошо работает с частичными шаблонами и блоками, а также другими элементами, необходимыми для более легкого создания умеренно сложных структур страниц, что является ключевым требованием даже для самой простой системы CMS, которую я бы хотел видеть. Идем дальше…

Dust

В настоящее время популярен из-за его применения в LinkedIn. На первый взгляд, очень похож на Mustache / Handlebars, но дополнен рядом полезных функций, таких как именованные блоки. Однако процесс загрузки шаблона и рендеринг выглядят довольно неуклюже, и он до сих пор не поддерживает довольно широкий спектр функций для построения страницы. Хорош, но недостаточно…

Nunjucks

Еще одна { { система на основе токенов } } , обеспечивающая (как и другие движки) логику, выполнение циклов и возможность управления переменными. Но кроме этого, шаблонизатор предоставляет продвинутые элементы построения страницы, например, наследование блоков, включая наследование макетов, пользовательские теги и макросы. Это все наилучшим образом подходит для системы CMS, где страницы представляют собой серию «строительных блоков».

Итак, у нас есть победитель!

Для справки

Основные примеры рендеринга

Давайте рассмотрим некоторые примеры шаблонизатора Nunjucks в действии…

Динамический рендеринг на платформе Node при использовании nunjucks.render

Во-первых, мы рассмотрим пример, в котором будем использовать Nunjucks для рендеринга страницы в ответ на запрос веб-службы, который обрабатывается сервером Node. Этот сценарий очень похож на тот, который происходит при запросе PHP или СoldАusion или страницы ASP .NET на обычном веб-сайте или в веб-приложении.

Предположим, что Node уже установлен.

Устанавливаем Express и Nunjucks:

Npm install express --save npm install nunjucks --save

Создаем нашу базовую структуру app.js:

Var express = require("express") ; var nunjucks = require("nunjucks") ; var app = express();

Настраиваем Nunjucks :

Var PATH_TO_TEMPLATES = "." ; nunjucks.configure(PATH_TO_TEMPLATES, { autoescape: true, express: app } );

Простой путь:

App.get("/home.html", function(req, res) { return res.render("index.html") ; } ); app.listen(3000);

Создаем шаблон index.html:

Привет всем

Запуск с:

Node app.js

и переходим на http://localhost:3000 . Готово!

Добавление динамических данных

Давайте быстро расширим этот пример, чтобы показать, как можно передать данные вашему шаблону в Nunjucks.

Для начала давайте передадим некоторые данные функции render:

App.get("/home.html", function(req, res) { var data = { имя: "Энди", фамилия: "Нил" } ; return res.render("index.html", data) ; } );

Во-вторых, мы будем ссылаться на эти данные в нашем шаблоне index.html:

Привет { { data.имя } }

Угадали, что произойдет, когда мы перейдем на http://localhost:3000 ?

Предварительная компиляция при помощи Gulp

Если у вас есть шаблоны, которые не опираются на динамические данные, тогда альтернативой их рендерингу по запросу будет использование инструмента Gulp (или Grunt, если он вам больше по душе) для предварительной компиляции данных во время компоновки.

Предположим, у вас есть простой сайт, состоящий из двух страниц со схожей разметкой:

• src/index.html
• src/contact-us.html
• src/_layout.html

Ваши странички могут выглядеть так:

Добро пожаловать

Контакты

Звоните нам на 0800 000 0000 или отправьте письмо на эл. адрес [email protected].

{ % block content %} { % endblock %}

Устанавливаем плагин gulp-nunjucks:

Npm install gulp-nunjucks --save

Создаем простой gulpfile.js в корневой папке проекта:

Var gulp = require("gulp") ; var nunjucks = require("nunjucks") ; var COMPILE = { SRC: "/src/**.html", DEST: "/dist’ } ; gulp.task("render", function() { return gulp.src(COMPILE.SRC) .pipe(nunjucks()) .pipe(gulp.dest(COMPILE.DEST)) ; } );

Запускаем процесс рендеринга:

Gulp render

Полученные в результате страницы HTML будут выглядеть так:

Добро пожаловать

Разве это не самый лучший сайт в мире?

Контакты

Позвоните нам на 0800 000 0000 или отправьте письмо на эл. адрес [email protected].

Особенности Nunjucks

Полную документацию можно посмотреть здесь:

В этом разделе мы затронем некоторые из основ для иллюстрации некоторых ключевых функций Nunjucks.

Наследование шаблона

Наследование шаблона - это самый простой путь к многократному использованию шаблонов. При написании шаблона можно определить «блоки», которые дочерние шаблоны могут переопределить. (Это то, что мы делали выше в разделе { % содержание блока %} ).

Таким образом, дочерний шаблон может наследовать у родительского шаблона и заполнять множественные, дискретные блоки в этом шаблоне. На самом деле, «цепочка наследования» может быть настолько длинной, насколько вам этого хочется. Так, например, отдельный раздел новостей на веб-странице может наследовать шаблон «новостной сюжет» (и другие страницы также могут иметь свои шаблоны, например, «блоги», «фото галерея»), который, в свою очередь, наследует родительский (базовый) шаблон, содержащий общие разделы для всех страниц сайта.

Включения

Обратная сторона расширений – это то, что они включают шаблон внутрь текущего шаблона. Это полезно для «вытягивания» блоков контента, которые используются в нескольких местах на сайте или в приложении.

Импортирование и макросы

Импортирование позволяет загружать шаблон и открывать любые переменные и макросы (функции), определенные в нем. Это может быть полезно для таких вещей, как создание функций для последовательного отображения полей формы... немного похоже на написание пользовательских тегов с помощью ColdFusion, например. Для наглядности давайте рассмотрим шаблон под названием forms.html , который выглядит так:

Мы можем импортировать этот шаблон и использовать его для быстрого рендеринга серии полей формы:

Это особенно полезно при использовании таких фреймфорков, как Foundation или Bootstrap , которые требуют разумного количества HTML и CSS сред - если у вас это получилось путем рендеринга в макросе, то код вашего шаблона будет гораздо проще. (Плюс, если ваш шаблон делает весь рендеринг через макросы, то он напрямую не привязан к фреймворку, что облегчает переключение фреймфорков, а также позволяет делать изменения, общие для всех полей формы определенного типа).

Логика – If / For / While

if проверяет состояние и используется для выборочного отображения контента или выполнения других операций:

for зацикливает массивы:

Var messages = ["Необходимо ввести адрес эл. почты", "Пароль должен быть не короче 8 знаков"];

Следующие шаги

Советую изучить официальную документацию Nunjucks для более ясного представления о свойствах и возможностях шаблонизатора.
В будущих обзорах я покажу, как можно скомбинировать возможности шаблонизатора Nunjucks с генератором статичных сайтов Wintersmith для построения своей собственной простой и многоязычной системы CMS.

Данная статья – обзор шаблонизаторов для фронтенд разработки . Если Вы работаете с JS, отличным и подходящим выбором являются шаблонизаторы, так как они дают возможность писать более чистый базовый код и упрощают работу с приложениями. Рассмотрим наиболее популярные шаблонизаторы JS, которые нам предлагает Википедия. Для того, чтобы качественно работать с данными шаблонизаторами, нужно иметь хорошое понимание языка и достаточное количество навыков в этой сфере.

ICanHaz.js – довольно простая и легкая библиотека, чтобы работать с шаблонами Mustache. С ним можно определять фрагменты шаблонов в тегах скриптов с type=”text/html” и вызывать их через id, с валидацией.

Mustache.js – очень популярный шаблонизатор в данной области применения. Он предоставляет решения для серверной и клиентской стороны, поэтому вам не нужно будет беспокоиться о использовании нескольких шаблонизаторов. Имеет хорошую и понятную документацию, а также большое сообщество. В шаблонах использует данных JSON формата. Отлично запускается на популярных языках программирования. Последнюю версию библиотеки можно скачать с офицальной страницы .

– расширение для Mustache и полностью с ним совместимо. Имеет большую скорость исполнения, так как не перегружен лишней логикой. HTML по тому же принципу генерируется из данных в формате JSON. Существенный недостаток – большой вес библиотеки.

Underscore.js – удобный и практичный инструмент для работы с jQuery. Имеет больше 60 функциональных утилит. Данный шаблонизатор усиляет функциональность jQuery при работе с массивами, функциями, объектами, коллекциями и т.д. 5 альтернатив jQuery UI .

Hogan.js – шаблонизатор, который разработала компания Twitter. Его используют в качестве компоновщика промежуточных шаблонов для их быстрой динамической обработки веб-браузером. В основу разработки данного шаблонизатора был положен Mustache, но Hogan.js работает намного быстрее. Для доступа к функциям парсера предлагается API. Сканирование шаблонов и парсинг исполняются отдельными методами, в результате чего шаблоны могут заранее обрабатываться на сервере, а на клиентской стороне использоваться в Javascript-виде.

– используют для работы с серверными шаблонами , но в общем применим и для других целей. Имеет высокую читабельность кода и хорошую безопасность. Функционирует из части клиента, есть возможность с помощью утилиты компилировать html-шаблоны из командной строки. Шаблонизатор переименован в Pug.js, но по старому названию можно найти большое количество документации и полезной информации для разработчика.

Шаблонизатор ECT разработан для повышения скорости. В его основе шаблонизатор Coffeescript. Имеет хорошую совместимость с Node.js и довольно простой синтаксис. Можно также ознакомиться с предварительными тестами, которые показывают производительность данной библиотеки.

Компания Hyper Host™ желает Вам приятной работы в мире JS и готова разместить Ваши замечательные проекты на нашем !

4366 раз(а) 3 Сегодня просмотрено раз(а)