これはヘルパーが行うことができます。
これを見てください： http ：
2つの値を比較できるifequalヘルパーがあります。
同様のソリューションを要件に使用できます。

怖かったです。
私はそのようなことがヘルパーでできることを知っています...しかし、つまり、ものを比較することは非常に基本的であり、デフォルトのパッケージに含まれているはずです。

それがパッケージに含まれているとしたら、とにかくそれはヘルパーになるでしょう。

@thany http://doginthehat.com.au/2012/02/comparison-block-helper-for-handlebars-templates/

@andriijasは非常に正しいです、それは確かにヘルパーになるでしょう;）if-blockはとても基本的であるため、そうではありません。
リンクをありがとう。 役に立ちますが、元のifを上書きする「ヘルパー」を作成して、それを_適切な_ifにするのが面倒です。 それは可能だと確信しています。 自尊心のあるテンプレートエンジンには、適切な条件付きフォーマットが必要です。 ハンドルバーも例外ではありません。

テンプレートにビジネスロジックを適用するハンドルバーのすべてがヘルパーであるという事実を克服する必要があります。

組み込みのすべて、ifなどはregisterHelperを介して定義されます。 チェック：
https://github.com/wycats/handlebars.js/blob/master/lib/handlebars/base.js

したがって、ヘルパーを使用しても「悪い」ことは何もありません。 ハンドルバーは、多かれ少なかれ単なる口ひげテンプレートコンパイラであり、ヘルパーを使用して追加のビジネスロジックを取得します。 おそらくレールか何かからの「ヘルパー」という言葉の使用について悪い経験をしているだけだと思う​​なら。

私は「ヘルパー」に何か問題があるとは決して言いませんでした。 私の見解では、適切なifステートメントが拡張であるとは考えられていないというだけです。 ヘルパー（これも私の見解では）は、CMSなどに固有のものです。 ヘルパーは、特別な操作または条件を実行するものです。 すべての人に向いているわけではありません。 つまり、コアライブラリの外部で定義されている場合です。 jQueryプラグインに少し似ているかもしれません。最も基本的なものは組み込みであり、始めるためのものです。 しかし、すべての人に適しているわけではないものは、コアライブラリの外部（つまりプラグイン）で定義されます。 jQuery-termsでは、単純なフィルター関数はプラグインではありません。

ifステートメント（私の見解では）は、このプラグインパラダイムには適用されません。 それは初歩的であり、プログラミングとテンプレートエンジンの最も基本的な原則の1つです...

その後、簡単なフォローアップ。 これが私がこれまでに得たものです：

Handlebars.registerHelper("when", function(lvalue, operation, rvalue, options) {
  console.log(arguments);
});

{{#when riskfactor eq 0}}...{{/when}}ようにテンプレートでこれを使用すると、コンソールに[6, undefined, 0, function()]配列が表示されます。 私が最後に手に入れるもの。 これは、このwhen-blockのコンテンツを処理するために呼び出す必要があるものです。 最初の3つ...まあ、それほど多くはありません。 「6」は実際には「riskfactor」の値です。 さて、私はそれで行くことができます。 未定義は私を超えています。 Handlebarsが入力オブジェクトでそれを評価しようとしていると思いますが、それは機能しません。 このような値は私のオブジェクトとは何の関係もないので、実際にはテンプレート内にあるものを取得したいと思います。

["riskfactor", "eq", "0", function()]ようなものを期待していました。 そうして初めて、私の関数は先に進んでそれを処理することができます。 「未定義」でそれをどのように行うのですか？

ハンドルバー（およびその他の「ロジックレス」テンプレート）の哲学は、テンプレートに到達するコンテキストはすでに完全に処理されている必要があるということだと思います。 アプリケーションの内部データ構造がテンプレートに適切なものと完全に一致しない場合（ほとんどの場合に当てはまります）、アプリケーションの内部データからテンプレートコンテキストを構築するテンプレートをレンダリングする前にステップを挿入する必要があります構造。

それが「ロジックとプレゼンテーションの分離」について語るときの意図だと思います。 ハンドルバーはMVCシステムのビューコンポーネントと考えてください。 あなたのモデルはすでに存在しています。 ここで記述しなければならないのはコントローラーだけです（この場合、モデルからビューへの一方向のバインディングのセットです）。

最近の質問に答えるには、これを使用します。

 {{#when "riskfactor" "eq" 0}}...{{/when}}

ハンドルバー式は、変数名または文字列のいずれかです。 変数名の場合、名前ではなく、現在のコンテキストで検索したときに変数の値を取得します。

一部の人が指摘しているように、これはハンドルバーの領域外です。

いいえ。
どのテンプレートシステムでも、単純な比較if-else-blockを実行できますが、ハンドルバーでは実行できません。 そのため、ハンドルバーは途方もなく不完全であるか、メーカーが無能であるか（これはありそうもないことです）、またはテンプレートシステムのタスクの視点が曇っているシステムになります。

その後、LOGICLESS TEMPLATEENGINEを使用しないでください。 KTHXBAI！

とった。 Toodles。

@ thany 、 @ andriijasはおそらく少し厳しいもの

ifヘルパーの@thanyを必要があります。 述語を渡すことができるはずです。 本当にその有用性を制限することができない。 ロジックレステンプレートの背後にある哲学は理解していますが、独断的な実装は実際には実用的ではありません（したがって、ヘルパーの存在ですよね？）。 これは、自転車会社が可変ギア比を追加するようなものであり、完全に合理的だと思います。

ところで、マシンに対して激怒してこれを実行したい場合は、述語を文字列として受け取り、それを評価するヘルパーを作成できます（そして、これを2回異端的にします：smiling_imp :)：

Handlebars.registerHelper('when', function (predicate, options) {
    var declarations = '';
    for (var field in this) declarations += field + ' = this.' + field + ',';
    if (eval(declarations + predicate)) { return options.fn(this); }
});

{{#when 'admin || superUser'}}
    crazy go nuts
{{/when}}

@thanyはベストプラクティスの観点から見て、バックエンドはすでに理解されているすべてのロジックでデータを提供する必要がありますフロントエンド（テンプレート）はそれをレンダリングする必要があります... 95よりもバックエンドオブジェクトの優れたJSON表現が得られた場合％ケースは、組み込み条件付きで満たすことができます

真剣に、行われたすべて（または95％）の決定がバックエンド指向であるわけではありません。 たとえば、レンダリングするクラス名を決定するには、テンプレートでその決定を行うのが完全に合理的です。 そのようなものは、フロントエンド/テンプレートに100％関連付けられています。 バックエンドは、どのクラス名がレンダリングされるかを気にする必要がありませんでした。 または、単数形/複数形の単語はどうですか？ これは、ifブロックでは実行できないもう1つのことです。

私の意見では、このような豊富なテンプレートを使用する場合、バックエンドはデータを提供する責任があり、データのみを提供します。 バックエンドが、テンプレートが決定を下す可能性のあるすべての状況に対して、テンプレートパーサーの既製の変数を提供する必要がある場合（ここではある程度の柔軟性を考慮して）、変数の膨大な量だけでなく、非常に複雑になります。それらを作るバックエンド。

テンプレートに必要なすべての決定がバックエンドで別の変更を必要とする場合は、HTMLをバックエンドに配置することもできます。 これにより、テンプレートの目的の大部分が失われます。 バックエンドに関連する決定は、まったく異なるレベルにあります。 ifブロックは必ずしもロジックではありません。 何をどのようにレンダリングするかを決めるだけです。

この問題にこれほど長い議論が必要だとは信じられませんが、適切なif-blockは本当に多すぎて要求できませんか？ :(

基本的な比較ヘルパーの実装については、賛成も反対もしませんが、これは、ヘルパーを使用したりデータ構造を変更したりせずにテンプレートをレンダリングできなかったと思われる非常に現実的なケースです。

    <select name="datatype">
      <option{{#ifeq type 'foo'}} selected="selected"{{/ifeq}}>foo</option>
      <option{{#ifeq type 'bar'}} selected="selected"{{/ifeq}}>bar</option>
      <option{{#ifeq type 'vaz'}} selected="selected"{{/ifeq}}>baz</option>
    </select>

しかし、繰り返しになりますが、私が書いたヘルパーは3行のコードでした。

    Handlebars.registerHelper('ifeq', function (a, b, options) {
      if (a == b) { return options.fn(this); }
    });

私は@thanyに同意し

テンプレートにロジックを含めることができないのはなぜですか？ ハンドルバーはどのようにロジックとプレゼンテーションの分離を提供していますか？ まだifステートメントがありますね。 単に存在や「虚偽」をテストするifステートメントは、（不）平等やその他の条件をチェックするifステートメントとまったく同じだと言っていますか？

唯一の（実際の）違いは、他のテンプレートライブラリとは異なり、ハンドルバーは「ロジックレス」を装って、上記のロジックの実装が非常に貧弱/不完全であるということです。 申し訳ありませんが、それはまったく無意味です。 ロジックを削除する場合は、 ifステートメントを完全に削除する必要があります。 ただし、ハンドルバーにifステートメントがまだあるのと同じ理由で、最終的にテンプレートにはロジックが必要になるため、これは行いません。

したがって、「ロジックをプレゼンテーションから分離する」というステートメント。 上記の理由だけでなく、テンプレートから「ロジック」を削除していないため、テンプレートの別の部分、つまりヘルパーに移動するだけで、コードが再利用される可能性があります。これは良いことです—そしておそらくそうではありません。その場合、他のヘルパーとほぼ/まったく同じことを実行するヘルパーがいくつでも得られる可能性があります。 if 。 これはどのように優れた設計上の決定ですか？

特定の「ロジック」が本質的に特定のビューにバインドされており、ビュー自体以外には重要性、重要性、および/または使用されていない場合、問題が正確に何であるかを理解するのにまだ苦労しています。 それは単に私にはmvc過激主義/やり過ぎのように聞こえます。

@andriijas別のテンプレートライブラリを使用できるとしたら、残念ながら決定は私の手に負えません。 そのため、「ロジック」を許可するテンプレートライブラリを使用するためのすべての推奨事項は、残念ながら耳が聞こえません。

誰かが実際に現在のifがどのように実装されているかを見たことがありますか？ （どちらがいいかを除いてもあります）

ifが現在どのように実装されているかを見てきたので、ハンドルバーがほとんどの人を満足させるシンプルでエレガントなデフォルトを持っている理由は、皆さんにとってより理にかなっているかもしれません。

拡張がいかに簡単かをここで見てください

https://github.com/elving/swag

https://github.com/elving/swag/blob/master/src/swag.comparisons.coffee

すべてのオープンソースプロジェクトが、ベーコンを調理するために必要なすべてのものを提供するのではなく、基礎だけを提供することを受け入れます。

@andriijasはい、 unlessはifであり、結果が反転します。 これがどのように補償するのかわかりません。 ヘルパーリポジトリリンクのおかげで、私はすでにヘルパーを書いていますが、これがどのように何かを補うのかわかりません。

ハンドルバーは10kb強（最小圧縮）で、盗品は3kb弱（最小圧縮）です。 したがって、コードベースに10kbのテンプレートライブラリを追加し、テンプレートにロジックを追加できるようにするためだけに、さらに3kbが必要になります。 あなたと他の何人かがあなたがとにかくあなたのテンプレートに持つべきではないと言っているロジック？

これは私の質問のいずれにも答えず、実際、 ifステートメントブロックの存在/偽以外の条件付きテストを禁止することは無意味であるという点を証明するのに役立ちます。

@andriijas /lib/handlebars/base.js#L97を見ていますが、どういう意味かよくわかりません。 何らかの形で別の使用法があるように見えますが、ドキュメントではこれを指定していません。 説明していただけませんか？

@constantology一部の人々は、たとえば、このスレッドの他の3kbを必要とするかもしれません。 githubでこのリポジトリにスターを付けた残りの3500は、ヘルパーを追加するか、テンプレートをレンダリングする前に実行することでロジックのニーズを解決したため、文句を言う可能性はほとんどありません。

@pikselが見ているのは、組み込みのifが、ヘルパーが遅いか何かであると考えて、多くの人が問題を抱えているように見える「アドオン」としての単なるヘルパーであるという事実です。

プロジェクトでヘルパーを使用しても問題はありません。 あるプロジェクトでは、いくつかのスワッグヘルパーを使用し、自分のview_helperファイルにコピーして、3k未満にしました。

あるバックボーンプロジェクトでは、ビューにgetTemplateDataメソッドがあります。このメソッドでは、複雑なロジックを簡単なものにまとめて、テンプレートをよりクリーンでわかりやすくします。また、ハンドルバーテンプレートよりもプレーンJavaScriptの単体テストを簡単に行うことができます。

@andriijasそれでも私の質問には答えません...

この時点で、私はすでに言ったことを繰り返しますので、私がすでに尋ねた質問のいずれかまたはすべてに実際に合理的な答えを提供できると思われる場合は、あなたがしなければならないことを聞いてとてもうれしく思いますいう。 :)

psリポジトリにスターを付けたり、ライブラリを使用している人の数は、必ずしもライブラリがどれだけ優れているかを示すものではありません。 Mac / Linuxを組み合わせたものよりも多くのWindowsユーザーがいて、どのブラウザー統計サイトを見ているかにもよりますが、最新のブラウザーよりもInternet Explorer 6、7、8を組み合わせて使用​​しているユーザーの数はまだ多くなっています。 これは、WindowsをosxやLinuxよりも優れたオペレーティングシステムにするわけではなく、古いバージョンのInternetExplorerを最新の標準で準拠したブラウザよりも優れたものにするわけでもありません。

この全体の議論は私には不吉です。 ifヘルパーがあります、それは論理的です。 したがって、論理のない議論全体は完全なストローマンです。 それは、車に転がるだけの窓があり、人々が不平を言って、それらも転がることを望んでいたようなものです。 そして、製造業者は、これらの車が機械的に制御された窓を持たないという厳格な哲学に従ったので、彼らはそれを変えるつもりはないと言いました...あなたはそれを支持するか支持しないかのどちらかです。 中途半端な実装は、ストローマンの議論で正当化されるべきではありません。

テンプレートにビジネスロジックがないことに完全に同意し、理解しています。 ただし、非常に簡単なテンプレートを実行している場合を除いて、そこにいくつかのビューロジックがあります。 ifヘルパーが存在するため、ハンドルバーは明らかにこれを認識します。 @thanyが指摘したように、コードに手に負えないifヘルパーを回避することは、答えではありません。 私は前にそれをしました、それは醜い速くなります。

@mikeobrienはい、前のコメントですでに述べました。 それは答えられなかった多くの質問の1つでした。

テンプレートにビジネスロジックがないことに完全に同意し、理解しています。 ただし、非常に簡単なテンプレートを実行している場合を除いて、そこにいくつかのビューロジックがあります。

うまく入れて。 ：^）

@constantology doh、申し訳ありませんが、過去のコメントをもっとよく読むべきだったと思います。 ：/

@constantologyに同意し

FWIWハンドルバーは本当にエレガントでよく書かれたテンプレートライブラリだと思います。

ブロックとヘルパーの概念は問題なく理解できますが、小さなことを行うためのヘルパーを作成することは、コアライブラリでサポートすることでよりエレガントに処理できるため、ロジックとプレゼンテーションを明確に分離することを意味するとは思いません。 CSSは条件文のサポートを追加しており、その一部はメディアクエリですでに実現できるため、 @ mikeobrienが言うように、純粋にプレゼンテーション言語のロジックは、単に「ビューロジック」である場合、必ずしも大きな問題ではありません。

if / unlessブロックに条件付きチェックがないというこの1つの制限により、エレガントでカプセル化されたテンプレートを作成するのが非常に難しいと感じています。

また、テンプレートを介してデータを解析する前にデータを前処理する方法があることにも同意しますが、データ構造全体を再フォーマットしてライブラリの意志に合わせるためではなく、単純な変更のみを目的としています。 どうして？

1. 複雑なデータ構造を取り、よりフラットなものを作成する必要がある場合、これは解析の全体的なパフォーマンスに影響を与える可能性があります。
2. 1に基づいて、元のスキーマに変更が加えられた場合、ビューコードがより脆弱になり、リファクタリングが困難になる可能性があります。
3. また、元のデータ構造をビューにマッピングしなくなったため、双方向のデータバインディングがより複雑になる可能性があります。これにより、変更を追跡するために必要なコードの量が増える可能性があります。

それらは私の頭から離れたところにあり、それを裏付けるための定量化可能な調査は行っていませんが、それは思考の糧です。 ：^）

元の質問の場合、比較のあるifヘルパーは間違ったものになります。 これは一般的なシナリオであり、次のようなヘルパーがあります。
{{#ifzerocount}}結果なし{{/ ifzero}}
{{#ifsingular count}} 1 result {{/ ifsingular}}
{{#ifplural count}} {{count}} results {{/ ifplural}}
もっと役に立ち、彼が本当にやりたいことを意味します。 現在のif構文は、空の値を表示する（しない）のに役立ちます。 非常に一般的なシナリオでもあります。 誰かが本当にifを必要としている場合、比較すると、それはビジネスロジックである可能性が非常に高く、テンプレートでそれを行うべきではありません。

それは確かにそれをするでしょう。
しかし、それが_原則的に_良いコーナーであるかどうかにかかわらず、開発者を特定のコーナーに強制するのはエンジン次第ではないと私はまだ考えています。 ビジネスロジックであり、テンプレートロジックであるのは開発者次第だと思います。

つまり、比較できないという制限が、どういうわけかそれをパラダイムにした純粋な技術的制限でない限りです。 これは、必要が生じた場合にそのような機能を追加できないことを意味するだけです。 私はそれが起こったことではないことを願っています。

感謝のテスト。 テスト。 このロジックを簡単にテストできないため、テンプレートに比較を入れたくありません。 セレンのようなものに接続してそこでテストするよりも、テンプレートのデータフォーマッターを使用して単純なブール値を作成してテストする方がはるかに簡単です。

これは単なる理論ではなく、「原則として」だけではありません。 テンプレートに比較さえ入れて、このロジックをテストしないのは、おそらく現実世界の技術的負債のでたらめでしょう。 これらのヘルパーを作成したり使用したりしないでください。 ハンドルバーにはまだヘルパーを使用していません。 ただし、ヘルパーを使用した場合は、ヘルパーをスパイしてテストし、実行されたことを確認できます。そのため、テンプレートに比較を組み込むよりも優れています。

比較を提供しないロジックフリーのテンプレートシステムはたくさんあります。 たとえば、goのように強く型付けされた言語では、平等とはどういう意味ですか？ Goテンプレートには比較はありません。 言語間で口ひげとハンドルバーの実装があり、それらは同じです。

テンプレートから比較のようなロジックを削除しても、生活が難しくなることはなく、簡単になります。 技術的負債は冗談ではなく、製品や企業さえも台無しにする可能性があります。

来て。
コマプリソンはそれほど難しくありません。 ロケット科学（または脳外科）ではありません。

非常に単純なマイクロテンプレートではロジックは必要ありませんが、さらに複雑になると、テンプレートにロジックが必要になります。 「テンプレートロジック」だけでなく「ビジネスロジック」などもあります。 何かのアイテムが1つ、2つ、または10つしかない場合にどうするかを決定します。 たとえば、ページング。 ディバイダ。 単純な「50％未満」と「50％超」のテキストで、続行できます。

他のテンプレートエンジンにもロジックがないという事実は、盲目的にそれらに従う必要があるという意味ではありません。 私の意見では、彼らも間違っています。

事実は、ある時点で、ビジネスロジックではないという理由だけで、ビジネスロジックに必要のない、または必要のないある種のロジックが存在するようになるということです。 現在または将来のテンプレートで必要になる可能性のある考えられるあらゆる種類の比較について、ブール値を持たなければならない他の開発者に納得することはできません。

「それは製品や企業さえも台無しにする可能性があります」？ 真剣に？
不適切な機能も可能です。

ほとんどの人が必要なものを出荷し、ヘルパーを追加することの何が問題になっていますか
あなたが必要なもののために？ 誰もが勝ちます。 それほど難しくはなく、ロケットのようではありません
理科。

ロケット科学の場合： https ：

2013年5月18日土曜日、thanyは次のように書いています。

来て。
コマプリソンはそれほど難しくありません。 ロケット科学（または脳外科）ではありません。

非常に単純なマイクロテンプレートでは、ロジックは必要ありませんが、ロジックがあれば
より複雑な場合は、テンプレートにロジックが必要になります。 そのようながあります
「ビジネスロジック」や「テンプレートロジック」など。 何をすべきかを決定する
何かのアイテムが1つしかない場合、2つ、または10個ある場合に実行します。 ページング、
例。 ディバイダ。 単純な「50％未満」と「50％超」のテキストで、続行できます。

他のテンプレートエンジンにもロジックがないという事実、
盲目的にそれらに従うべきだという意味ではありません。 彼らも間違っています
意見。

事実は、ある時点で、あなたはちょうどあなたがちょうどある種の論理を持っているだろうということです
それがビジネスではないという理由だけで、ビジネスロジックを必要としない、または望んでいない
論理。 ブール値を持たなければならない仲間の開発者には納得できません
で、現在または将来の考えられるあらゆる種類の比較について
テンプレートが必要になる可能性があります。

「それは製品や企業さえも台無しにする可能性があります」？ 真剣に？
不適切な機能も可能です。

—
このメールに直接返信するか、Gi tHubhttps：//github.com/wycats/handlebars.js/issues/206#issuecomment-18104713で表示してください
。

ほとんどの人はそれを使用していないが、ここで説明されている問題が原因である可能性があります：ロジックがありません。 したがって、もちろん、積極的に使用するほとんどの人は、多かれ少なかれそれに満足するでしょう。

@thany私はあなたを感じ、私はあなたに同意します。

ハンドルバーの後ろの人はこれをあきらめたくないと思いますが、ねえ、私があなたに言うつもりのことは素晴らしいニュースです：
プロジェクトを_フォーク_し、パッチを追加して、独自のフォークを使用できます。
gitの魔法のおかげで、 git pullするだけで、新しいバージョンについていくのはかなり簡単なはずです。

そしてそれを待つ、それは良くなります。

これが大きなニーズであり、全体的に優れている場合、おそらく人々はあなたのフォークを使い始めるか、さらに良いことに、ハンドルバーの後ろの人があなたのフォークを元の/マスターにマージします：dancer：

良いものを持っている; D

私が自分自身に時間を与えるならば、確かに！

私は@constantologyに絶対に同意します。 その非常識なテンプレートにはロジックがありません。 そして、ロジックのないテンプレートが必要な場合は、なぜそこに：「if」ステートメントを配置します。これは、ロジックを赤色の危険として表します...意味がありません。 スープの塩としては、基本的な比較ロジックが必要だと思います。 @mikeobrien ：「

ロジックレステンプレートについては、言いたいことがあります。 ただし、問題は、ここにいる全員がビジネスロジックとビューロジックを混同していることだと思います。 ビジネスロジックはテンプレートにはありません。 期間。 ただし、ビューロジックはまったく別の問題です。 ハンドルバーはこれを認識していると思います。そのため、最初にif / elseを追加しましたが、途中で少し混乱しました。

データ配列に1つまたは複数の項目があるかどうかを知る必要があり、それに基づいてそれらをコンマで結合するか、単語に複数形を追加します。 現在のifブロックでは、これを行うことはできません。

これが、私がこのプルリクエストを行った理由です： https ： http ：//jsfiddle.net/YsteK/

このプルリクエストは、新しいヘルパーifTestを提供します。これは、JavaScriptがコンテキストを指定するのと同じように評価するjavascript式を取ります。 楽しみ。

正直なところ、これはそのような基本的な機能であり、フレームワークにロジックが組み込まれていないというこの考え方に固執したい場合（私には完全に非論理的です！）、「if」などの論理用語の使用を再考する必要があると感じます。 。

これを多くのプロジェクトに追加しているのは、「0」や「1」などを他のブール値と比較するときに非常に役立つからです。

Handlebars.registerHelper（ 'ifCond'、function（v1、v2、options）{
if（v1 === v2）{
options.fn（this）;を返します。
}
options.inverse（this）;を返します。
}）;

既存の「if」機能をそのように機能させることは完全に公正だと思いますが、英語を支持して別の単語を選択します（または人々が期待するとおりに機能させます）。 他のコンテキストで真のifステートメントのように動作しない場合、「if」という用語の本当の転覆のように感じます。

if完全に削除するか、 ifがいくつかの基本的な比較引数（ eq 、 ne 、 gtを受け入れることを許可するための別の投票を追加したいと思います。 {{#if arg1 eq arg2}}ます。 もちろん、 if完全に削除することは、「テンプレートにロジックがない」という哲学にとってより理にかなっています（現在、「テンプレートにロジックがない_ほとんどの場合_が_時々_大丈夫」のようなものです）。

ヘルパーがいなければ、私はいつもこのようなことをすることになります：

<select>
    <option value='ak' {{#if ak_selected}}selected{{/if}}>AK</option>
    <option value='al' {{#if al_selected}}selected{{/if}}>AL</option>
    <option value='ar' {{#if ar_selected}}selected{{/if}}>AR</option>
    <option value='az' {{#if az_selected}}selected{{/if}}>AZ</option>
    <option value='ca' {{#if ca_selected}}selected{{/if}}>CA</option>
    ....
</select>

これらすべての余分なプロパティをオブジェクトに追加するのはちょっとばかげているようです。

webgovernor-これをチェックしてください： http ：//jsfiddle.net/YsteK/

これは、この機能を有効にするヘルパーです。 javascriptがコンテキストを与えられたのと同じように評価するjavascript式を取ります。 楽しみ。

tniswongに感謝します、それは私のヘルパーに非常に似ています。 私は問題を解決しました。ハンドルバーの「ロジックレス」ドグマの偽善を強調したかっただけです。

問題ない。 私はあなたと一緒にいます。 私はハンドルバーが大好きですが、このヘルパーなしではかなり役に立ちません。

このヘルパーをプルリクエストとして送信しましたが、拒否されました。 そこで、ifブロックを削除する別のプルリクエストを送信しました。 また、拒否されました。 /はぁ

ははは。 Githubには賛成ボタンが必要です。

拒否されましたか？ -_-

ハンドルバーの論理のない宗教の頑固さは本当に気が遠くなるようなものです。

566および＃568

彼はそれをREADMEに追加するかもしれないと言ったが、私は息を止めていない。

これに+1！ Argghhh！

FWIW、 Swagリポジトリは、比較、並べ替え、その他の気の利いたものを追加するヘル​​パーを提供します。 私はそれなしではハンドルバーで何も構築しません。

とは言うものの、私はハンドルバーをクリーンで拡張可能で保守しやすい状態に保つため、ハンドルバーを可能な限りロジックレスに保つことに個人的に同意します。 さらに必要な場合は、プロジェクトの範囲外のものについては、_Swag_のようなリポジトリに貢献してください。 このプロジェクトのメンテナが気が変わった場合、必要なのはプルリクエスト：+1：だけです。

@aboutaaron 「ハンドルバーをクリーンで拡張可能で保守し

1. ハンドルバーにロジックが含まれていないことを証明します。 スレッドを読んだ場合、ハンドルバーに「真実性」のみをチェックするifステートメントの形式の不完全なロジックが含まれていることがすでに証明されていることがわかります。スレッドを読んでいない場合は、そうすることをお勧めします。
2. ハンドルバーが不完全なロジックを提供するifステートメントの形式で、何らかの方法で「真実性」のみをチェックし、「クリーンで拡張可能かつ保守可能に保つ」という証拠を提供します。
   これは矛盾ではありませんか？ ハンドルバーが拡張可能である場合、それは条件文の完全な実装を提供することは簡単であることを意味しませんか？
   たとえば、完全なifステートメントを提供するハンドルバーは、ハンドルバーとスワッグを使用する開発者よりもクリーンで拡張性が低く、保守し
   比較演算子ごとに異なるヘルパー、つまりgt 、 gte 、 isを使用する必要があるため、スワッグヘルパーを使用すると、コードベースのクリーン性、拡張性、および保守性が低下すると主張することができます。 is 、 isnt 、 lt 、 lte 、および各論理演算子、つまりand 、 or 。
   これにより、他の言語でifステートメント内で行うのと同じようにコードを読みやすくすることができますか？ もしそうなら、プログラミング言語自体が「真実性」以外のものをチェックする条件文を廃止すると思いますか？ 私はこれが起こっているのを見ていません。

たまたま「ビジネスロジックをテンプレートに入れる」といううんざりした、そして反証された議論を使用する場合は、使用しないでください。 これは、このスレッドですでに数回、数人の人々によって対処されています。 同時に、それが有効な引数であると考える場合は、前のステートメントと矛盾して、 swagライブラリを使用する必要がなくなります。

結論として、ハンドルバーでのifの不完全な実装に完全性を追加しようとするライブラリがいくつかあるという事実は、何らかの形で、このタイプの機能が必要であることを示しています。芯。 JavaScript言語自体を見てください。ハーモニーは、サードパーティのライブラリ、イテレータ、モジュール、ジェネレータ、クラス、プロキシなどによって提供されている多くの機能を導入しています。 また、DOM APIは、サードパーティのライブラリであるquerySelector [All]、CORSによって提供される機能も実装しており、ChromeCanaryにはDOMPromisesも実装されています。

「ハンドルバーをクリーンで拡張可能かつ保守可能に保つため、ハンドルバーを可能な限りロジックレスに保つ」という証拠はありません。 同時に、他の人と私は、このスレッドの以前のコメントで、ハンドルバーが完全なif実装を提供する場合、開発者に統合APIを提供することで、少しは大いに役立つ可能性があることを示しましたそれらのテンプレートは読みやすく、保守しやすいです。

@ constantology + 1アーメン。

{{#ifsomething> something_else}}を試し、この状況の真実に気づいた後、私はちょうどここに到着しました。 しかし、私はこれに関するハンドルバーの人々に同意したいと思います。 私は長い間液体を使用していましたが、このようなコメントスレッドは必然的に、バックエンドに実際に属していた数学や文字列の連結などの半ば焼きの機能の追加につながります。

「ロジックレス」のifステートメントの目標は、バックエンドでロジック部分を実行し、ハンドルバーに「answer」を単一の変数として提示することです。 答えが「はい」の場合はこれを行い、そうでない場合は他のことを行います。 （上記のコメントを読んで）問題は見当たらないので、今すぐコードを修正します。

いくつかのEmberアプリケーションに取り組んでいて、私の意見を取り入れたかったのです。 #ifステートメントは、_（オプションで）_引数を受け入れた方がよいと思います。 私は物事をlogic-lessままにしておきたいという願望を完全に理解していますが、時には一緒に仕事をするのはかなりイライラすることがあります。

選択または選択解除された質問の簡単なリストを想像してみてください。 本当に、これらの2つのロジックブロックの違いは何ですか？

{{#if isSelected question}}
  <p>This question is selected</p>
{{else}}
  <p>This question is NOT selected</p>
{{/if}}

{{#if question.isSelected}}
  <p>This question is selected</p>
{{else}}
  <p>This question is NOT selected</p>
{{/if}}

これらの2つの例を裏付けるコードを書く必要がある方法にはかなり大きな違いがあります。 どちらかを選択できる柔軟性があると本当にいいでしょう。 また、最初のロジックに2番目のロジックよりも多くのロジックが含まれていることもわかりません。

このスレッドが言っているのとまったく同じことを感じました。 そして、このスレッドを見つけました。
したがって、私はハンドルバーの哲学を理解したと思います。
次に、必要なのはSwagのようなヘルパーコレクションであることがわかりました。

Swagが私を助けてくれるので、今は問題ありません。
ただし、デフォルトのifヘルパーが単純すぎるため、混乱しました。
Hanlebarsにロジックがないと言うなら、Handlebarsに組み込みのヘルパーが必要だとは思えません。
ヘルパーが内蔵されていなければ、ハンドルバーの哲学をより理解しやすいと思います。

logic-lessとbusiness logicについてよく理解していないかもしれませんが、私が考えたことをお話ししたいと思います。

「{{foo}}」のようにブールデータを表す手段であるため、（条件なしで）単一のif / unlessをロジックと見なすことはできないと思います。構文は、文字列データを表す手段です。

したがって、次の動作を停止する必要があると思います。「ロジックがない場合、なぜifステートメントがあるのですか？HA-HA、チェックメイト!!!」

次に、「{{＃if}}」ではなく「{{#exists}}」に変更します。これは、より理にかなっているためです。

2013年10月5日には、10：52 AMで、cal127 [email protected]書きました：

「{{foo}}」のようにブールデータを表す手段であるため、（条件なしで）単一のif / unlessをロジックと見なすことはできないと思います。構文は、文字列データを表す手段です。

したがって、次の動作を停止する必要があると思います。「ロジックがない場合、なぜifステートメントがあるのですか？HA-HA、チェックメイト!!!」

—
このメールに直接返信するか、GitHubで表示してください。

：thumbsup：{{＃if}}を{{#exists}}または{{#isTrue}}に変更する場合

もっと賢明な名前を見つけることができることに同意します。 'exists'はそれを行い、私の提案は 'true'または 'on'になります。

しかし、それでもなお、歴史的な理由から、「if」という名前の方が適切です。 ハンドルバーのif実装は、構文的に他のif実装と同じであり、古い「if（[predicate]）[dosth]」構文に準拠しています。

異なるのは、[述語]は裸のブール変数でなければならず、式にすることはできないということです。 しかし、これは「if」の制限ではありません。 これは、ハンドルバーインタープリターの式がサポートされていないために発生する、より一般的な制限です。 （これがハンドルバーをロジックレスにしている理由だと思います）

つまり、この「if」は他の「if」と何ら変わりはありません。

そして、「もし」の名前を変えようとすることは、異端と見なされる人もいるかもしれませんが、私があなたに警告しなかったと言ってはいけません。

{{#if}}と{{#unless}}行うことはそれだけなので、 {{#truthy}}と{{#falsey}} {{#if}}と呼びます。

開発者の方へ：頭を砂から出してください。 真剣に。 適切なifステートメントに対する要求があることがわかります（そして私は「要求」という言葉を文字通り使用するつもりです）ので、論理がないことについて泣き言を言うのではなく、それを実装してください。 テンプレートをロジックレスにしたい場合は、 {{#if}}と{{#each}}を含むすべてのロジックを廃止します。

適切なifステートメントを実装するだけです。
論理がないことを強く信じる人々は、それを使わないことを選ぶでしょう。 単純。 NS。 それか。

私もあなたのために仕事をしました。

https://github.com/wycats/handlebars.js/pull/566
https://gist.github.com/tniswong/5910264

2013年10月5日には、15:20で、thany [email protected]書きました：

{{#truthy}}と{{#unless}}が行うのはそれだけなので、{{＃truthy}}と{{#falsey}}と呼びます。

開発者の方へ：頭を砂から出してください。 真剣に。 適切なifステートメントに対する要求があることがわかります（そして私は「要求」という言葉を文字通り使用するつもりです）ので、論理がないことについて泣き言を言うのではなく、それを実装してください。 テンプレートをロジックレスにしたい場合は、{{＃if}}と{{#each}}を含むすべてのロジックを廃止してください。

適切なifステートメントを実装するだけです。 論理がないことを強く信じる人々は、それを使わないことを選ぶでしょう。 単純。 NS。 それか。

—
このメールに直接返信するか、GitHubで表示してください。

それをありがとう、しかし解決策はコアパッケージにあるべきです。 「ifTest」という用語は、ハンドルバーが「if」という用語を使用する前にハイジャックしたためと考えられます。

もう1つは、ifTestが文字列を受け取り、実行時にその文字列の評価を行うのに対し、適切なifブロックがコアパッケージにある場合は、コンパイルされたテンプレート（ハンドルバーの強力なものの1つ）にある可能性があることです。ポイント-ifsやelseにeval()を使用して船外に投げるのが好きではないもの）

あなたは100％正しいです。 当時私が利用できたツールを使用するだけです。

とにかく、それは動作します。

2013年10月5日には、15:41で、thany [email protected]書きました：

それをありがとう、しかし解決策はコアパッケージにあるべきです。 また、「ifTest」という用語は、ハンドルバーが「if」という用語を使用する前にハイジャックしたためと考えられます。 もう1つは、ifTestが文字列を受け取り、実行時にその文字列の評価を行うのに対し、適切なifブロックがコアパッケージにある場合は、コンパイルされたテンプレート（ハンドルバーの強力なものの1つ）にある可能性があることです。ポイント-ifsやelsesにeval（）を使用して船外に投げるのが好きではないもの）

—
このメールに直接返信するか、GitHubで表示してください。

ハンドルバーで比較を検索しているときに、このスレッドに偶然出くわしました。 {{#if}} {{#each}}ブロックと

テンプレートは非開発者（つまりデザイナー）が読めるようにするべきだという意見が開発者の間であると理解しています。 しかし、A）これが問題となったデザイナーと一緒に仕事をしたことは一度もありません。B）一般的なソリューションが組み込まれていることをアプローチする必要があると思います。拡張機能として、ブール値のみのチェックを使用できるため、次のようになります。選択。 さらに、 {{#ifValueEqualsA}}や{{#ifValueEqualsB}}ようなヘルパーを追加すると、単に必要のない多くの定型コードを作成する必要があります。 私はそれほど大きくないモバイルプロジェクトで働いており、特定のニーズの比較を追加するだけの200行のコードがすでにあります。 これは、（願わくば）すべての開発者の考え方に反します。

@ cal127 「（条件なしで）単一のif / unlessをロジックと見なすことはできないと思います」-では、何が問題なのでしょうか。 ブール値をチェックするよりも式をチェックする方が論理的であるのはなぜですか？ 小切手です。 期間。 これは、式ではなく、ここで実行されるロジックです（ブール値は、式を推測するため）。 もちろん、式がビジネスではなくUIロジックを表すと仮定します。

ロジックレステンプレートエンジンのアイデアはすでに瀕死のようです...私はこれが将来も続くとは思いません。 開発者は、物事をより簡単かつ迅速にするツールを必要としています。

@thanyrocks 。 私は昨日口ひげ（別の論理のないテンプレート言語）について来ました、そしてこれはまさに数分後に私の頭に浮かんだ質問でした。 プログラマーはこれがクールだとどう思ったのでしょうか。 これは事態を悪化させるだけです。 私が知っているプログラミングパラダイムは、「BUSINESSロジックとPRESENTATIONロジックの分離」です。 そのdefは、プレゼンテーションにロジックがあることを意味します（たとえば、mvcのようなパターンでテンプレートを含む/含むビュー）。 なぜ彼らはそれを否定し、プレゼンテーションからロジックを削除しようとしているのですか。

シナリオ：ビューでループを実行していて、x回の反復後にアクションを実行したい。 ハンドルバーを使用して、ヘルパーを作成してからループで使用する必要がありますか？ これはどのように私の人生を楽にしますか？ count == xの場合はどうなりましたか????? テンプレートにphp自体のような言語を使用するよりも、それはどのように優れていますか？ 論理テンプレートエンジンの設計にどのように役立ちますか？

自分？ ロジック指向のジョブには、ロジックのないものはありません。 ごめん！

私はあなたがどれほど無知であることができるか信じられません、論理のない親愛なる信者。 それはただの現実ではなく、完全な神話、誤謬、偽りの宗教です。 数行を超えるテンプレートが完全にロジックレスになることはありません。 それは単に実用的ではありません。

さて、あなたのユーザーにそのような信念を強制することは完全にあなたの決定です。 しかし、論理に対する要求を一掃し続けることは、愚かさと無知の証拠です。 特にこの特定のケースでは、ごくわずかではありますが、すでに可能な量のロジックがあるためです。

繰り返しになりますが、再考することを強くお勧めします。 いいえ、待って、再考しないでください。 ただ聞いて正しいことをしてください。 テンプレートにそのばかげたロジックを望まない人は、ロジックを使用しないように、先に進んで邪悪な方法を続け、あらゆる種類のフープを飛び越えることができます。

適切な比較を行うためにif-blockを拡張しても、現在の使用法が失われることはありません。 まだ論理的な光を見たことがない人にとっては問題にはなりません。それらの人はそのままコーディングを続けることができます。

かっこいいということではありません。 あなた自身が論理の分離を議論として使用し、それを無視してあなたの人生を単純化するように求めます。 標準のハンドルバーテンプレートライブラリをプロジェクトに追加するか、独自に作成することができます。

あなたまたは他の誰も、多数のスレッドのいずれかでこれに反対する多数の議論のいずれかに対処していません。 これらの議論がこのスレッドで明確になるように：
1）既存のエコシステムを破壊します。 これは、更新したいが2年以内に独自のIFを持っているチームにとって、競合とやり直しを引き起こします。
2）必要に応じて追加する既存のヘルパーライブラリと、次に要求する他のすべてのヘルパーがあります。
3）この「if」を追加することが合意されるとすぐに、新しい引数はそれの実装になります。 名前。 構文。 引数。 それが表示された場合、あなたは満足すると約束するかもしれませんが、他の人はそうしません。 すぐに新しいスレッドがここにあり、他の方法で機能するはずだと主張しています。
4）既存の「if」はまさに-rendering-のためにあるべきものです。 「Yが存在する場合はXを表示する」。 それはビジネスロジックについてではありません。 これはモデルで発生するはずです（Backboneをお勧めします。そうすれば、モデルのisXXX（）メソッドにするだけで、好きなものを使用できます）。

私たちはお互いに物事を求めているので、大きな変更を加えるためのかなり良い技術的な議論がない場合は、これを続けないでください。 欲求不満になるのはばかげています-必要な「IF」を追加して完了します。

1）いいえ、しません。 何もしなくても、テンプレートは機能し続けるはずです。 もちろん、すべてが下位互換性がある必要があります。 そうでない場合でも、単にアップグレードしないでください。
2）ifステートメントは基本です。 あなたが言っているのは、車のホイールがオプションになっているようなものです。
3）ifステートメントの構文はほとんど重要ではありません。 すべてのプログラミング言語には1つあり、それらのすべてがまったく同じことを行います。 だから1つを選んでください、そしてそれは大丈夫でしょう。 さらに重要なことは、適切なifステートメントがあることは、現在のステートメントよりも優れていることです。
4）間違っています。「テンプレートロジック」を上向きに検索してください。

あなたの最後のスタンスについては、議論がなされており、それは健全です。 それは何度も何度も議論されてきましたが、それは本当に宗教のように見えます。 壊れない、それでもとても壊れやすい。

ジョージフリック-

1）これは、これまでに存在した他のフレームワークまたはライブラリのアップグレードとどのように異なりますか？
2）その通りです。 ただし、これらの基本的な機能を手動で追加することは、それほど基本的で必要なことには必要ありません。
3）それがプルリクエストの目的です。
4）あなたは完全に要点を逃しました。 このスレッドの誰も、ビューレイヤーのビジネスロジックについて議論していません。 ビューレイヤーでの有用な表示ロジックについて議論しています。 与えられた「if」は真のifではないため、プログラミング言語を使用したことがある人にとっては混乱を招きます。 それはもっと「存在する」ものです。

これを追加すると、人々がテンプレートでビジネスロジックを使用するようになると思われる場合は、愚かなことを修正できないため、おそらく正しいでしょう。 誰かが悪いことをすることができるからといって、その過程で他の人が良い（そして必要な）ことをするのを防ぐべきだという意味ではありません。

2013年11月22日には、3：55 PMで、ジョージ・フリックの[email protected]は書きました：

かっこいいということではありません。 あなた自身が論理の分離を議論として使用し、それを無視してあなたの人生を単純化するように求めます。 標準のハンドルバーテンプレートライブラリをプロジェクトに追加するか、独自に作成することができます。

あなたまたは他の誰も、多数のスレッドのいずれかでこれに反対する多数の議論のいずれかに対処していません。 このスレッドで議論が明確になるように、それだけです。
1）既存のエコシステムを破壊します。 これは、更新したいが2年以内に独自のIFを持っているチームにとって、競合とやり直しを引き起こします。
2）必要に応じて追加する既存のヘルパーライブラリと、次に要求する他のすべてのヘルパーがあります。
3）この「if」を追加することが合意されるとすぐに、新しい引数はそれの実装になります。 名前。 構文。 引数。 それが表示された場合、あなたは満足すると約束するかもしれませんが、他の人はそうしません。 すぐに新しいスレッドがここにあり、他の方法で機能するはずだと主張しています。
4）既存の「if」はまさに-rendering-のためにあるべきものです。 「Yが存在する場合はXを表示する」。 それはビジネスロジックについてではありません。 これはモデルで発生するはずです（Backboneをお勧めします。そうすれば、モデルのisXXX（）メソッドにするだけで、好きなものを使用できます）。

私たちはお互いに物事を求めているので、大きな変更を加えるためのかなり良い技術的な議論がない場合は、これを続けないでください。 欲求不満になるのはばかげています-必要な「IF」を追加して完了します。

—
このメールに直接返信するか、GitHubで表示してください。

@thany
議論を反証することとそれを却下することには違いがあります。 「WRONG」は「NUHUH！」に相当します。
それについてもそれほど個人的にならないようにしてください。

@tniswong
1）そうではありません。これは、どのフレームワークにも当てはまります。
2）これを一般的な意味で適用する場合、ノードにはそのすべてのコンポーネントが含まれている必要があります。 それらが基本的または必要であるということは議論の余地がありますが、標準的なフレームワークの外でそれらをすべてグループ化することは優れた抽象化と分離であるという考えにつながります。 多くのプロジェクトはそれらのどれも必要とせず、他のプロジェクトは特別なバージョンを必要とします。 したがって、標準セットをプラグインするか、独自に作成するか、何も使用しないでください。 これらすべてのヘルパーがデフォルトでロールインされるという技術的に妥当な理由は（再び）ありません。
3）あなたの声明は、実際、元のポイントを否定するものではありません-あなたはそれを助けます。 Ifを修正するための20のプルリクエスト。 私は、開発チームがそれらを通過するのが大好きになるに違いありません。
4）正確には、それは「存在する」です。 存在する場合はこれをレンダリングします。
「誰でも」について書くことができないとき、それは単一の反例を取ります。 _手を上げる_。

上記のメモから、次のいずれかが必要であるように思われます。

1. if名前をexists 、ハンドルバーを「ロジックレス」と呼ぶのをやめます（そうではないため）
2. ifステートメントとして動作するifサポートを追加します。
3. if完全に削除します。

私はそれらのオプションのいずれかに満足しています。

{{#unless}}を忘れないでください

2013年11月22日には、16:40で、アーロンMの[email protected]は書きました：

上記のメモから、次のいずれかが必要であるように思われます。

存在する場合は名前を変更し、ハンドルバーを「ロジックレス」と呼ぶのをやめます（そうではないため）
ifステートメントとして動作するifのサポートを追加します。
完全に削除します。
私はそれらのオプションのいずれかに満足しています。

—
このメールに直接返信するか、GitHubで表示してください。

これが本当に要約すると、アーロンによってうまく要約されていると思います。

1. 論理がないと主張し、if / unlessを提供することによって対処する必要がある偽善があります。
2. 与えられた「if」は誤った名称です。

それらの両方を修正すると、この議論はなくなります。

2013年11月22日午後4時43分、Todd [email protected]は次のように書いています。

{{#unless}}を忘れないでください

2013年11月22日には、16:40で、アーロンMの[email protected]は書きました：

上記のメモから、次のいずれかが必要であるように思われます。

存在する場合は名前を変更し、ハンドルバーを「ロジックレス」と呼ぶのをやめます（そうではないため）
ifステートメントとして動作するifのサポートを追加します。
完全に削除します。
私はそれらのオプションのいずれかに満足しています。

—
このメールに直接返信するか、GitHubで表示してください。

@georgefrick
私は彼の議論を、それが何百万回も前に反証されたという理由だけで却下していました。 私たちはこれをあまりにも長い間乗り越えてきました、そしてそれは終わらせなければなりません。 ifステートメントを追加する必要があります。誰も不利益を被ることはなく、誰もが幸せになります。 それを望まないことは、すべての家でエアコンを望まないことと同じです。 私は私の家に何が欲しいかを判断します。 それがあなたのものであり、あなたがそれを望まないならば、それをそのままにしておいてください。 そのような単純な。

@webgovernor
名前を変更する必要はありません。 適切なifステートメントは、現在のステートメントと完全に互換性を持たせることができます。 現在、これは「if boolean then ...」であり、完全な機能を備えたifステートメントはまさにそれを実行しますが、1つの変数だけでなく、そのブール値のみを任意の式にすることができます。

@tniswong
それらのどれほど素晴らしいでしょう？ 実装されたif-blockが非常に単純化されているため、式を否定することさえできないため、不潔な余分なタグを追加します。 しかし、将来のハンドルバーでは、unlessタグが単に「ifnot」のエイリアスになる可能性があります。 プログラミングでは、do..whileとwhile..doのようなものがあります。この場合、2つは主に読みやすさのために存在し、技術的な理由で実際には存在しません。

私も、ハンドルバーの基本的な比較を望んでいます。 私は論理のない哲学を理解しています。 また、基本的な比較サポートはより直感的であり、ユーザーがより効率的に作業できるようになると思います。 大量のユーザーが基本的な比較ロジックをヘルパーに移動している場合、この哲学は、ユーザーに好意を示したり、知覚された次善の動作を思いとどまらせたりするのではなく、より多くの作業を作成するだけです。

@jeremiahleeあなたがそこで私に賛成か反対かわからない、私はあなたのコメントをどちらの方法でも読むことができます:)

いずれにせよ、私は過去にハンドルバーを使用したことがあり、適切なifブロックを実装するように要求しました。 これは、論理がモデルに残るべきであるという偽の哲学についてのコメントの雪崩をもたらしました。 ハンドルバーの開発者は、自分たちの小さな世界の外で1ミリほど考えたいとは思っていませんでした（そのための失礼な言葉がありますが、スキップします）。 このスレッドを証拠として見てください。

これにより、比較を行う「when」というヘルパーを作成する必要がありました。 まだ適切なif-block構造はありませんが、当時の私には十分に近いものです。 しかし、それは私にとって多くの不必要な仕事を生み出しました。

@thany ：ハンドルバーに2つの値の基本的な比較が組み込まれている必要があることに同意します。ロジックレステンプレートも共感がないものであってはなりません。

@thanyやその他の議論にも投票します。 if elseステートメントはあまりにも基本的です。
条件クラスとselectボックス、事前に選択してoption sがハンドルバーのデフォルトパッケージでなんとかする必要があります。

ネストされたヘルパーを使用すると、これはもはや問題ではありません。

{{#if (greater-than array.length 3)}}
  ...
{{/if}}

良い例@mmun ：+1：

少し奇妙で、ブールコンビネータは見当たりません...しかし、何よりも、このプロジェクトのメンテナの全体的な見方は変わりません。これは、壊れない「NO LOGIC !! 11 !!」のようです。 1！1 "のようなビュー。