先ほど 、Emberのヘルパーはバージョン1.13で導入されたと述べました。 私の意見では、ヘルパーはEmberの最も便利な機能の1つですが、あまり議論されていません。
EmberConf 2016での講義Idiomatic Emberでは、ヘルパーについて詳しく説明し、それらを使用してHandlebarsの機能を接続および大幅に拡張する方法を示しました。
これらは宣言型テンプレートに使用できます。これは、構成アクションを使用するテンプレートスタイルであり、プレゼンテーションロジックに対するテンプレートの責任をより大きくします。
DockYardの同僚Marten Schilstraと一緒に、アドオンember-composable-helpersを作成しました。 これは宣言型ヘルパーのパッケージであり、これを使用すると、アプリケーションの定型コードの量を減らすことができます。 次のようにインストールできます。
ember install ember-composable-helpers
アドオンで私のお気に入りのヘルパーの1つはpipe
（およびそのクロージャーバージョンであるpipe-action
）です。 コンポーネントで多くのオプションを作成する代わりに、テンプレートで宣言的にアクションを構成できます。
{{perform-calculation add=(action "add") subtract=(action "subtract") multiply=(action "multiply") square=(action "square") }}
{{! perform-calculation/template.hbs }} <button {{action (pipe add square) 2 4}}>Should be 36</button> <button {{action (pipe subtract square) 4 2}}>Should be 4</button> <button {{action (pipe multiply square) 5 5}}>Should be 625</button>
パイプヘルパーは、Elixirパイプオペレーター（ |>
）に触発され、次の記述が可能になります。
A(B(C(D(E), "F"), "G"), "H")
コンバーターのチェーンとして：
E |> D() |> C("F") |> B("G") |> A("H")
パイプ演算子を使用すると、自然にE
D
関数に渡され、結果の値が最初の引数としてC
渡されるというように自然に表現できます。 パイプ版の方がずっと読みやすいことに同意できると思います！
ヘルパーの力しか知らないなら
ヘルパーは、EmberとHTMLBarsを使用してHandlebarsによって提供される式を拡張するプリミティブなKeyWord
コンストラクトであると考えるかもしれません。
最も基本的なレベルでは、Handlebarsはhbs
テンプレートをHTMLにコンパイルします。
<p>{{myText}}</p> <!-- : --> <p>Hello world!</p>
EmberおよびHTMLBarsはこの上に構築され、 action
、 mut
、 get
、 hash
などの便利な式を追加します。 実際、（ each
component
からeach
component
）使用する使い慣れたヘルパーはすべてHTMLBarsの一部です ！
EmberヘルパーはHTMLBarsヘルパーよりも高いレベルで機能し、Emberで新しい式を作成するために使用でき、独自の動作でテンプレートを効果的に拡張できます。
それはすべて状況に依存します。
より経験豊富なまたは保守的な開発者は、これが危険であると感じるかもしれません。
たとえば、Elixirでは、マクロを使用して言語を拡張できますが、 実際の使用にはお勧めできません。 これは、エリクサーに関する Chris McCord Metaprogrammingの優れた本-「ルール1：マクロを使用しないでください」に記載されています。
幸い、ヘルパーはElixirマクロほど強力ではなく、Emberプログラミングモデルで重要な役割を果たします。 ASTに到達できるマクロとは異なり、Emberヘルパーを使用してプレゼンテーションロジックを拡張することは 、 それを悪用するまで受け入れられます。これが、エクスペリエンスの出番です。 ヘルパーを賢く使用してください。
芝生からロジックを外して
ヘルパーを含むアドオンを使用すると、テンプレートに多くのロジックを導入しすぎないように誤解されているため、ヘルパーを使用することに不快感を覚える場合があります。
ベストプラクティスとして、次のようなネストされた構造を使用するだけでなく、テンプレートの複雑なロジックを控える必要があります。
{{#unless (or (and (gte value 0) (lt value 0.0001)) (and (lt value 0) (not allowNegativeResults)))}} ... {{/unless}}
代わりに計算プロパティを使用してください。
同時に、テンプレートをロジックから100％自由に保つことは非常に困難です。ほとんどのif/else
またはexceptのような論理ヘルパーを既に使用している可能性があります。 テンプレート内のロジックの量が厳密に定義されていないという事実を簡単に見落とす可能性があります。
未来に戻る
ember-composable-helpers
は、実際には、テンプレート内のロジックの量を大幅に増やすことはありません。正しく使用すると、これらのヘルパー内にプレゼンテーションロジックがカプセル化され、多くの場合、コンポーネントまたはコントローラーの冗長コードを排除できます。
たとえば、アプリケーションに次のようなものを書くことができます。
import Ember from 'ember'; const { Component, computed: { filterBy, setDiff }, set } = Ember; export default Component.extend({ activeEmployees: filterBy('employees', 'isActive'), inactiveEmployees: setDiff('employees', 'activeEmployees') });
他のコンポーネントで使用するメディエーションコンポーネントを使用するのは、かなり一般的な方法です。 ember-composable-helpers
を使用すると、このような構成をテンプレートに直接書くことができます。
<h2>Active Employees</h2> {{#each (filter-by "isActive" engineers) as |employee|}} {{employee.name}} is active! {{/each}} <h2>Inactive Employees</h2> {{#each (reject-by "isActive" engineers) as |employee|}} {{employee.name}} is inactive! {{/each}}
コンポーザブルヘルパーは、テンプレートで直接使用して作成できる、計算されたマクロプロパティの一種と考えることができます。 また、Emberでサブ式を作成できるため、アプリケーションの定型コードを削減するための強力な構造体になります。
上記を考慮すると、深いネストに夢中になりすぎないでください。
最適なソリューション
他のプログラミングツールと同様に、常識を使用して賢明に使用することが重要です。
あなたが何かできるなら、それはあなたがすべきだという意味ではありません。
適切に作成されたビューレイヤーとは、テンプレートを可能な限り宣言的（すべてが明白）にする必要があることを意味し、ロジックをまったく避けるべきではありません。
それでも、すべてのロジックをテンプレートに移動することは好ましくありません。テンプレートのロジックの量は厳密には規制されていません。
アドオンの使用方法を確認するには、 Katherin Siracusaが AlphaSightsで ember-composable-helpers
composable ember-composable-helpers
を使用する方法に関する優れた記事を書きました。
このパターンを使用すると、データに対して操作を実行でき、将来的にはアプリケーションで常に発生する、より補助的な短期アクションを実行できます。 構成可能なヘルパーを使用することで、多くの重複や不要な副作用を心配することなく、非常に簡単にこれを行うことができます。
Slackチャンネル#e-composable-helpers
のディスカッションにも参加でき#e-composable-helpers
。
いつものように、ご清聴ありがとうございました！