Handlebars.js: ハンドルバーはテーブルでは機能しません

価値があるのは、{{each}}タグがテーブルの外に配置されている場合、他のタグが機能することです。 もちろん、これはテーブルを繰り返し複製する場合に望ましくない影響を及ぼしますが、おそらく問題を絞り込むのに役立ちます。

http://jsfiddle.net/cwYhN/6/

これはjQueryなどの問題のようです... console.log(frag);実行すると、ハンドルバーでコンパイルしようとする前でも、 {{#each}}ヘルパーがテーブルの外にプッシュされていることがわかります。 ..。。

テンプレートを<script type="text/x-handlebars-template"></script>タグ内に配置するようにjsfiddleを更新しましたが、正常に機能しているようです...

http://jsfiddle.net/doowb/6GdPy/1/

ええ、私はちょうど自分自身を発見しました：
http://jsfiddle.net/cwYhN/10/

価値があるのは、jqueryの欠陥ではなく、ブラウザが無効なhtmlと見なすものを破棄していることだと思います。

ええ、それがjQueryのものなのか、jQueryが呼び出すネイティブブラウザ関数なのかはわかりませんでした。 いずれにせよ、 tbodyとtr間の{{ }}は好きではありません。

ハンドルバーがこの制約内で動作するように何らかの方法で構築されていると便利です。 たとえば、タグの内容を反復処理することを暗黙的に理解しながら、タグ内に「each」を配置できること。 私はそれが次のように見えると想像するかもしれません：

<table>
  <tbody handlebars="{{each}}">
    ... these get iterated ...
  </tbody>
</table>

このようなことを許可すると、ブラウザーが重要な各ステートメントを削除するのを防ぎ、それが属する終了タグ（/ tbody）に便乗する可能性があります。

皆さんがすでにほのめかしているように、HTMLパーサーはハンドルバーのマークアップによって混乱し、ハンドルバーテンプレートに変換しようとするDOM構造としてこれを思い付きます。

            {{#each activity}}

            {{/each}}
        <table style="border:1px solid #ccc;">
        <thead>
            <tr><th>Month</th>
            <th>Imps</th>
            <th>Clicks</th>
            <th>Spend</th>
        </tr></thead>
        <tbody><tr>
                <th>{{month}}</th>
                <td>{{impressions}}</td><td>{{clicks}}</td><td>{{spend}}</td>
            </tr></tbody>
    </table>

これを回避するには、上記のスクリプトの動作、JavaScript文字列、またはプリコンパイルなどを使用する必要があります。

この問題はハンドルバー自体のバグというよりもブラウザの実装の詳細であるため、これを締めくくります。

{{#each}}がテーブルで機能しないことがわかる前に、ちょうど半日無駄になりました。 これが単にドキュメントに記載されていれば、本当に役に立ちます。

適切にロードされていれば、それぞれがテーブルで完全に正常に機能します。 テンプレートをどのようにロードしていますか？

@preicheltブラウザがテーブルの{{#each}}を台無しにしないように、スクリプトタグ内からハンドルバーをロードする必要があります。 あなたはスタックオーバーフローについてもっと読むことができます：

http://stackoverflow.com/questions/15386276/why-should-we-wrap-our-templates-inside-script-blocks

このバグは私の人生の2時間無駄になり、現在は土曜日の午後10時30分です。この問題と[Official Block Doc]が見つかるまで、このバグを解決するためだけにオフィスで働いています。
（http://handlebarsjs.com/builtin_helpers.html）はそれについて何も述べていません。

明確でない場合、これはハンドルバーのせいではありませんが、HTMLがどのように機能するかを知らないのはあなたのせいhttps ：//html.spec.whatwg.org/multipage/syntax.html#an -introduction-to-error -パーサー内の処理と奇妙なケース

それで、Handlebarsjsを使おうとするすべての人が、HTMLパーサーがどのように機能するかをよく理解している必要があると思いますか？ そうでない場合、それは_ユーザーのせい_であり、ドキュメントの明確さのせいではありませんか？ この仮定は意味がありません。 もう1つの重くて複雑なテンプレートエンジンであるAngularjsは、テンプレート構文としてHtml互換の構文を使用します。たとえば、テーブルをループする必要がある場合は、次を使用できます。

<tr ng-repeat="dto in tableData">

また、Angularjsは、Htmlコメントを使用してループの内部ステータスを保持します。

<!-- ngRepeat: column in row -->
<tr ng-repeat="dto in tableData">

Angualrjsは、可能な限りHtmlの構文を尊重して従おうとし、この仮定をうまく回避しようとします。 ただし、Handlebarsjsのテンプレート構文はそうではないため、Htmlパーサーの問題がユーザーに公開されます。
開発者があなたの側で問題を解決できない場合、あなたがあなたのプロジェクトと世界中のユーザーを本当に気にかけているなら、あなたはあなたのユーザーに問題を認識するように伝える_義務_を持っています。
とにかく、私はドキュメントの問題を開きます。なぜなら、私はこの頭痛の問題に遭遇した最初の人ではなく、最後の問題ではないと信じているからです。 _

AngularはDOMで実行されるため、DOMを認識します。 ハンドルバーは文字列でのみ機能し、DOMの概念はありません。

@profullstack ： @stevenvachonが言ったように、ハンドルバーはHTMLでは機能せず、テキストでのみ機能します。 ただし、すべての例がHTMLであるため、これはドキュメントからは明らかではない場合があります。 個人的にはマークダウンを生成するためにも使用します...

ドキュメントにどのようなテキストが必要か教えていただければ、喜んで追加させていただきます。 ただし、一般的な使用方法（ <script>タグの付いた部分を含む）は、 http： //handlebarsjs.com/のメインページに既にあります

@profullstack 「時間の無駄」に不満を感じているようですが、私の意見では、これは完全に逆行しています。

オープンソースプロジェクトや寄稿者はあなたに対していかなる義務も負いません。 ハンドルバーのようなツールは、他の開発者の生活を楽にするために、無料でほとんど感謝せずに作成および保守されています。 オープンソースプロジェクトをまったく使用できなかったとしたら、どのくらいの時間がかかりましたか？

このような口調でコメントを書いてみると、期待した効果とは

@ErisDSアドバイスありがとうございます。 私の最初のコメントは強すぎたかもしれませんが、私はあなたの意見に完全に同意します：

to try to making other developers lives easier

そして、なぜAngularjsを削除してHandlebarsjsを使用するのですか？ _HandlebarsjsはAngularjsよりも私の生活を楽にしてくれると信じているからです。_
それで、潜在的な問題を回避するために何千ものオープンソースユーザーが「他の開発者の生活を楽にする」というあなたの意志に反するのを助けるために、ドキュメントにいくつかの通知語を親切に追加してください。 いいえ、違います。
にとって：

No open source project nor contributor has any duty to you.

はい、それは本当だ。 オープンソースプロジェクトを開始してからドロップすることができます。まったく問題ありません。 しかし、プロジェクトが成長すると、プロジェクトにより多くの時間と心を費やし、プロジェクトをより愛し、世界と共有したいと思うようになります。 この時点で、_ユーザーのことを気にする_と_ドキュメントのことを気にする_ことから始めます。 Handlebarsjsはこの段階にあり、これは小さなプロジェクトではなく、人気のあるプロジェクトであり、韓国や中国など、世界中のプログラマーによって使用されています。
私の知る限り、Githubのほとんどのオープンソースプログラマーは、プロジェクトとREADME.mdファイルを誇りに思っており、より多くの人々がツールとコードを使用することを望んでいます。
したがって、次の場合：

• オープンソースユーザーを気にしたくない
• 私はこの問題に遭遇する最後の人です
  最初のコメントでの私のテクニカル分析とこのコメントでのユーザーの親切な議論は完全に無視できます。
  その上、オープンソースプロジェクトはあなたが世界に与える_慈善_のようなものではなく、あなたと他のプログラマーの間の_コミュニケーションの架け橋_です。

@nknappお返事ありがとうございます。
たぶん私の最初のコメントは強すぎるので、それと私のコメントを読んだ人々に謝罪します。
一見したところ、ハンドルバーは_テキスト置換ツール_のように機能し、非常に理解しやすいものです。 だから私がこのようなものを書くとき：

{{#each myListData}}
                        <tr>{{name}}</tr>
{{/each}}

それが単なる交換である場合、私は次のようなものを期待します：

<tr>nameA</tr>
<tr>nameB</tr>

しかし、HTMLに出くわしたとき、それは別の動作をします。それは、 @ stevenvachonが親切に述べたようにHTMLパーサーの
したがって、「各ブロックヘルパー」セクションの下には1文だけで十分だと思います。

WARNING: please use script block when you try to use #each block inside table, due to the know issue of [How HTML parse works(thanks for <strong i="18">@stevenvachon</strong>'s reference](https://html.spec.whatwg.org/multipage/syntax.html#an-introduction-to-error-handling-and-strange-cases-in-the-parser)

ご意見をお聞かせいただければ幸いです。 ありがとう。

問題は、これは#eachヘルパーとは何の関係もないということです。 テンプレートを直接HTMLに記述しないでください。 このようなステートメントはメインページにあるはずですが、質問は次のとおりです。そこで読んだでしょうか。

たぶん、ランディングページの例の下にあなたのような警告を出すことができます...

ちょうど別の注意：

本番環境ではscript-blocksメソッドを使用しません。 代わりに、Webpackまたは別のツールを使用してテンプレートをプリコンパイルします。

@nknappはい、あなたの意見は正しいと思います。テンプレートをHTMLに直接書き込むことは絶対にしないでください。 したがって、ランディングページでは、最初の「はじめに」セクションで例としてスクリプトを使用する必要があり、以下の灰色のブロックで変更できます。

You **can** deliver a template to the browser by including it in a <script> tag.

に

You **should always** deliver a template to the browser by including it in a <script> tag.

私はあなたの提案を推測します：

**never** write a template directly into HTML

は完全に正しいので、ランディングページに配置して、全員がこれに従うことができるようにする必要があります。これにより、多くの問題を回避できます。 いい考えだと思いますが、そう思いますか？

しかし、彼らはそれを次のように理解するかもしれないので、その説明は機能しません：

<script type="text/x-handlebars">
  {{#each list as |item|}}
    <td>{{item}}</td>
  {{/each}}
</script>

@stevenvachonはい、スクリプト内にテンプレートを配置するだけでは不十分です。テンプレートの正しい使用方法に関するメモを追加する必要があるかもしれません。これについての提案をお聞かせください。

多分：

ほとんどの本番アプリケーションでは、パーサーと文字列のテンプレートを使用したくないでしょう。 プリコンパイルを調べてください。

@stevenvachonコメントありがとうございます。HTMLパーサーリンクをコメントと一緒に配置するとよいと思います。

ほとんどの本番アプリケーションでは、パーサーと文字列のテンプレートを使用したくないでしょう。 プリコンパイルを調べてください。 テンプレートをHTMLに直接使用する場合、いくつかの既知の問題があります。たとえば、 HTMLパーサーの動作が原因で、＃eachブロックヘルパーがテーブル内で機能しません

おそらく分割する必要があります

1. <script>タグの例のすぐ下

テンプレートを<script>タグ内に配置することが重要です。 HTMLに直接入れないでください。HTMLパーサーが変更する可能性があります（たとえば、テーブルが含まれている場合）。

1. プリコンパイルに関する箇条書きをに変更します。

このアプローチは、実稼働アプリケーションには推奨されないことに注意してください。 テンプレートをプリコンパイルすることも可能です。 [...]

実際、私は個人的にブラウザでハンドルバーを使用しなくなりました。他にも多くのフレームワークがあります（AngularとReactだけでなく、VueとRactiveも）。 このビデオはかなりクールで、問題を示しています...

私はサーバー上で静的ページジェネレーターとしてハンドルバーを使用していますが、ブラウザーのレンダリングにはもっと良い方法があると思います。

@nknapp VDOMを介してブラウザに取り込むために-html-parserを書き始めましたが、抵抗に見舞われました。

@nknappお返事ありがとうございます。 あなたのコメントは次のとおりです。

1. テンプレートを内部に配置することの重要性

@profullstack私はこのプロジェクトの

変更を加えました。

@nknappありがとうございます。多くの人があなたの変更から恩恵を受けると思います。

この問題はかなり古いことは知っていますが、Sendgridの電子メールテンプレートエディタがこれらのベストプラクティスに従わなかったため、最近これに遭遇しました。 その理由で他の誰かがGoogleからこの問題に遭遇した場合、回避策はハンドルバーコードをHTMLコメントに配置することです。

<table >
  <tbody>
    <!-- {{#each items}} -->
    <tr>
      <td>{{this.key}}</td>
      <td>{{this.value}}</td>
    </tr>
    <!-- {{/each}} -->
  </tbody>
</table>

次の出力を生成します

<table>
  <tbody>
    <!--  -->
    <tr>
      <td>my key</td>
      <td>my value</td>
    </tr>
    <!--  -->
    <!--  -->
    <tr>
      <td>my key 2</td>
      <td>my value 2</td>
    </tr>
    <!--  -->
  </tbody>
<table>

（注：Sendgridのテンプレートエディターで、ハンドルバーを使用してこれを直接確認していません）

そのヒントをありがとう@gurpreetatwal 。 SendGridのちょっとした情報で、今夜のデバッグにかかる​​時間を節約できました。

@gurpreetatwalしかし、なぜですか？

@Lazarencjuszなぜ修正が機能するのか、または

やあ！ テーブルの代わりにdiv要素を使用すると、が機能します。
また、すべてのテーブル要素をdivに書き換えます。

@gurpreetatwalのソリューションは、ハンドルバーをテンプレート化するMailchimp / Mandrillsで機能します。 たくさんのトラブルを救ってくれてありがとう！