web-dev-qa-db-ja.com

Dust.jsを使用したクライアント側テンプレートの基本的な例

これはクライアント側のテンプレート化への私の最初の進出であり、私がそれを理解し、それを正しく使用していることを確認したいと思います。 このLinkedInエンジニアリングブログ を読んだ後、 moustache ではなく dust.js を使用することにしました-または ハンドルバー 。 このstackoverflowの投稿 は私の質問の多くに答えましたが、それでも明確にしたいことがいくつかあります。

私が使用している環境では、サーバー側には何もアクセスできないため、作成するすべてのものがクライアントのブラウザーで完全に実行できる必要があります。この例では、 LinkedInダストチュートリアル から このコードサンプル を再作成します。

テンプレートをオンザフライでコンパイルするため、dust-core.jsではなくdust-full.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);
    });
});

this jsfiddle で確認できるように、これは正常に動作するようです。

いくつかの質問：

  1. テンプレートをスクリプトタグ内に含める必要があるのはなぜですか？なぜそれをid = "entry-template"を含むdivに含めて、 この変更されたフィドル のように、dust.render（）の間にその内部のhtmlを置き換えないのですか？

  2. "dust.loadSource（compiled）;"は何をしますか？ docs にはと表示されます "ロードしたJSのスクリプトブロックの一部として「コンパイル済み」文字列を含めると、「イントロ」テンプレートは定義して登録します。すぐに実行したい場合は、 "呼び出しますが、それが何を意味するのか理解できません。その行を削除すると機能しないことに気づきましたので、理解したいと思います。

  3. テンプレートに満足し、それを確定したら、ページを読み込むたびにブラウザーでコンパイルするのではなく、軽量のdust-core.jsをインポートするように、どのようにコンパイルする必要がありますか？これを行うことには大きな利点がありますか、それともdust-full.jsのままにしておくべきですか？

  4. より一般的には、これはダスト（またはその問題のテンプレートフレームワーク）を実装するための適切な/便利な方法のように見えますか、それとも私はどこか離れていますか？

前もって感謝します。

linkedindust.jsclient-side-templating
19
dougmacklin

  1. divに配置すると、ページが読み込まれるとすぐにマークアップがレンダリングされ、ダスト__{placeholder}_構文が含まれます。その後、クライアント側のレンダリングが発生すると、完全にレンダリングされたコンテンツに突然置き換えられます。簡単な例では、これは非常に速く起こり、気付かない場合があります。ただし、テンプレートのダウンロード、ダストJSライブラリ、JSONのフェッチ（まだページに埋め込まれていない場合）、ブラウザーのJSパフォーマンス、およびページで発生しているその他の処理にかかる時間に応じて、このスイッチはユーザーにとって非常に目立ちますが、これは良い体験ではありません。

  2. ダストテンプレートをコンパイルすると、出力はJavaScript関数を含む文字列になります。次のようになります。

    （function（）{dust.register（ "intro"、body0）; function body0（chk、ctx）{/ * [...] * /}}）（）;

    この文字列をdust.loadSourceに渡すと、evalそれだけで、この自己呼び出し関数が実行されます。その結果、_dust.register_呼び出しが実行され、_body0_関数が_dust.cache_内の名前introに関連付けられます。その後、dust.render("intro"...)を呼び出すたびに、dustは_dust.cache_でintroテンプレートを検索し、それに関連付けられた関数を実行します。

  3. 上記の例の_dust.compile_などの_.js_ファイルに_intro.js_の出力を保存します。次に、他のJavaScriptファイルと同様に、ページに_dust-core.js_および_intro.js_を含めることができます（例：_script tags_内またはローダー経由）。

  4. 通常、各ダストテンプレートを_intro.tl_などの個別のファイルに保存し、何らかのビルドシステム（例 http://gruntjs.com/ ）を使用して自動的に変更されるたびに_.js_ファイル。次に、生成されたすべての_.js_ファイルを単一のファイルに連結し（gruntもこれを実行できます）、scriptタグでページにロードします。

11
Yevgeniy Brikman

  1. テンプレートをスクリプトタグに含める必要はありません。2番目の方法の方が適しています。

  2. loadSourceは、テンプレートのコンパイル済み出力を実行します。これには、他のテンプレートおよびdust.renderがその名前（この場合は「intro」）を介してコンパイル済み出力チェーンを参照できるように、登録が含まれます。

  3. これには、ブラウザーを開く前にテンプレートを事前にコンパイルすることが含まれます。したがって、すべてのテンプレートが.tlファイルとして含まれているフォルダーがあるとします。いくつかのビルドステップでは、これらすべてのテンプレートを（dust.compileを使用して）コンパイルし、出力を.jsファイルとして保存します。次に、ブラウザは実際にそれらの.jsファイルをロードします。これにより、dust.loadSourceの必要性もなくなります。ここでの利点は、最大3000行のコードを追加するコンパイラーとパーサーを含める必要がないことです。ダストライブラリのサイズは、4000行のコードからわずか800行のコードになります。編集：また、あなたが言及したように、あなたはブラウザでテンプレートをその場でコンパイルしているわけではないので、それはまた大きなパフォーマンスの向上になるでしょう。

  4. 上で述べたビルドステップが欠けている以外は、あなたは正しい道を進んでいると思います。

1
prashn64