Базовый пример создания клиентской стороны с Dust.js

Это мой первый набег на шаблоны на стороне клиента, и я хочу убедиться, что я понимаю его и правильно его использую. После прочтения этого инженерного блога LinkedIn я решил пойти с dust.js, а не усы или handlebars. Обратите внимание, что этот postoverflow post ответил на многие мои вопросы, но у меня все еще есть несколько вещей, которые я хочу уточнить.

В среде, в которой я работаю, у меня нет доступа к чему-либо на стороне сервера, поэтому все, что я создаю, должно полностью работать в клиентском браузере. В этом примере я попытаюсь воссоздать этот пример кода из Учебное пособие по LinkedIn Dust.

Я включаю dust-full.js, а не dust-core.js, потому что я собираюсь скомпилировать шаблон на лету:

<script src="js/dust-full.js"></script>

Вот HTML:

<script id="entry-template">
{title}

<ul>
    {#names}
    <li>{name}</li>{~n}
    {/names}
</ul>
</script>

<div id="output"></div>

И JavaScript (с использованием jQuery):

$(document).ready(function () {
    var data = {
        "title": "Famous People", 
        "names" : [{ "name": "Larry" },{ "name": "Curly" },{ "name": "Moe" }]
    }

    var source   = $("#entry-template").html();
    var compiled = dust.compile(source, "intro");
    dust.loadSource(compiled);

    dust.render("intro", data, function(err, out) {
        $("#output").html(out);
    });
});

Кажется, что все работает отлично, как вы можете видеть в этот jsfiddle.

Несколько вопросов:

  • Почему шаблон должен содержаться в тегах script? Почему бы просто не включить его в div с id = "entry-template", а затем заменить html внутри этого во время dust.render(), как в этот измененный скрипт?

  • Что делает dust.loadSource(скомпилировано); "делать? В docs говорится:" Если вы включили "скомпилированную" строку как часть блока script JS, который вы загружаете, тогда будет определен и зарегистрирован шаблон "intro". Если вы хотите сделать это немедленно, тогда "назовите его, однако я не понимаю, что это значит. Я заметил, что если я удалю эту строку, тогда это не сработает, поэтому я хотел бы это понять.

  • После того, как я доволен своим шаблоном и завершаю его, как мне его скомпилировать, чтобы импортировать более легкую dust-core.js, а не компилировать ее браузером на каждую загрузку страницы? Есть ли существенное преимущество для этого или я должен оставить, как есть, с помощью dust-full.js?

  • В общем, похоже ли это как подходящий/полезный способ реализации пыли (или любой шаблонной схемы, если на то пошло), или я просто где-то далеко?

Спасибо заранее.

Ответы

Ответ 1

  • Если вы поместите его в div, разметка будет отображаться сразу после загрузки страницы и содержать синтаксис пыли {placeholder}. Затем, после рендеринга клиентской стороны, он внезапно будет заменен полностью отображаемым контентом. В простом примере это может случиться так быстро, что вы этого не заметите. Однако в зависимости от того, сколько времени требуется для загрузки шаблонов, пылевых JS-библиотек, получения JSON (если он еще не встроен в страницу), производительности JS браузера и других вещей, происходящих на странице, этот переключатель может быть очень заметным для пользователя, что не является хорошим опытом.

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

    (function() {dust.register( "intro", body0); function body0 (chk, ctx) {/* [...] */}})();

    Когда вы передаете эту строку в файл dust.loadSource, все, что она делает, это eval it, выполняя эту функцию самозапуска. В результате выполняется вызов dust.register, который связывает функцию body0 с именем intro в dust.cache. После этого каждый раз, когда вы вызываете dust.render("intro"...), пыль просматривает шаблон intro в dust.cache и выполняет связанную с ним функцию.

  • Сохраните вывод dust.compile в файле .js, например intro.js для примера выше. Затем вы можете включить dust-core.js и intro.js на странице, как и любые другие файлы JavaScript (например, в script tags или через загрузчики).

  • Обычно вы храните каждый шаблон пыли в отдельном файле, например intro.tl, и используете какую-то систему сборки (например, http://gruntjs.com/) автоматически скомпилировать его в файл .js каждый раз, когда он изменяется. Затем вы объединяете все сгенерированные файлы .js в один файл (это может также сделать хрюкать) и загружать его на странице в теге script.

Ответ 2

  • Вам не нужно содержать шаблон в тегах script, ваш второй способ лучше.

  • loadSource будет запускать скомпилированный вывод вашего шаблона, который включает в себя его регистрацию, чтобы другие шаблоны и dust.render могли ссылаться на скомпилированную производственную цепочку через ее имя ( "intro" в этом случае).

  • Это включает предварительную компиляцию ваших шаблонов, прежде чем вы даже откроете браузер. Таким образом, у вас может быть папка со всеми вашими шаблонами как .tl файлы. На каком-то этапе сборки вы должны скомпилировать все эти шаблоны (используя dust.compile) и сохранить вывод в виде файлов .js. Тогда браузер действительно загрузит эти .js файлы. Это также избавляет от необходимости использования dust.loadSource. Преимущество здесь заключается не в том, чтобы включать компилятор и синтаксический анализатор, которые составляют до ~ 3000 строк кода. Размер библиотеки пыли составляет от 4000 строк кода до всего 800 строк кода. EDIT: Кроме того, как вы упомянули, вы не собираете шаблоны "на лету" в браузере, так что также будет большой прирост производительности.

  • Я бы сказал, кроме пропущенного шага сборки, о котором я упоминал выше, вы на правильном пути.