Handlebars.js: 機能の提案| 同期/非同期ヘルパー

これは過去に発生したことがありますが、ユースケースが明確ではなかったため、私たちはそれに基づいて行動しませんでした。 ハンドルバーは、すべてのデータがレンダリングに使用できるようになるまで待機する必要があるため、非同期評価を提供することは、コンテキストを生成するコードがはるかに効率的な方法で実行できることの便宜にすぎません。

基本的に、この時点で非同期評価を追加すると、互換性と実行時のパフォーマンスの両方の点で非常にコストがかかりますが、現時点ではユースケースはあまり見られません。 あなたがやろうとしていることの具体的な例はありますか？

パフォーマンスの問題には同意しますが、RegisterHelperやRegisterHelperAsyncなどのオプションでaysncにすることができれば、もっと良いと思います。

実際、node.jsを使用しているときに、これらの非同期ハンドルバーについて考えるようになりました。 私はexpress.jsを使用していくつかのアプリケーションに取り組んでおり、使用するテンプレートエンジンはハンドルバーです。 したがって、ビューのコンパイル中にデータベース呼び出しから値を取得する必要がある場合、この同期動作では不可能です。

例えば、

Handlebars.registerHelper('getDbValue', function(id) {
     var Model = require('./myModel.js');
     Model.getValue(id, function(data){
           return data;
     });
});

上記の例は機能せず、何も返しません。 以下は私のコンセプトです。 そして、それが完全に正しいのか、それとも実装できるのかどうかはわかりません。 非同期メソッドの場合、returnの代わりにコールバック関数を使用するだけです。

Handlebars.registerHelperAsync('getDbValue', function(id, callback) {
     var Model = require('./myModel.js');
     Model.getValue(id, function(data){
           callback(data);
           //or
           //callback(new Handlebars.SafeString(data)); //in case of safestring.
     });
});

上記のような問題がさらに発生しています。この機能に興味がある人がいれば、シナリオに応じてさらに多くの例を示すことができます。

ありがとう

@robincsamuel 、ビューの生成にデータベースルックアップを含める場合、MVC分離の全体的なアイデアはウィンドウに表示されます。 ビューがレンダリングされるまでデータが必要かどうかわからないかもしれないと主張していると思いますが、ビューを生成するときではなく、コントローラーレベルで実装する必要がある機能を提案しています。 @kpdeckerが言及したパフォーマンスの考慮事項と組み合わせると、非同期ヘルパーは間違っているように見えます。 -私の2c

私は自分の問題を伝えるためにその例を使用しました。 そして、私は議論しようとはしていませんが、ただ提案をしました。 ヘルパーからのコールバックを使用して関数を呼び出すと役立つことを願っています。 とにかく、お時間をいただきありがとうございます:) @kpdecker @jwilm

この時点でのプロジェクトのスタンスは、テンプレートを呼び出す前にデータ解決を行う必要があるということです。 テンプレートの懸念の内外のビジネスロジックの外では、非同期解決は、非同期などの他のライブラリが処理にはるかに適しているよりもユーティリティの動作です。

コメントしたいのですが。 DBの例ではウィンドウが表示されなくなりますが、これはミューテーションテンプレートに非常に役立つ可能性があります。 たとえば、内部に「サブビュー」があり、他のいくつかのテンプレートに分割したくないテンプレート。 ビュー全体を再描画する（ちらつき効果）か、コントローラーにこれらすべての「ミニビュー」のすべてを構築させる代わりに、ビューの一部を更新し、そのための単純なロジックを用意したいだけです。

どう思いますか？

@tomasdevつまり:)

この機能は、 https：//github.com/barc/express-hbsを使用すると、Expressのノードで利用できるようになります。 ただし、非同期バージョンのヘルパーは、部分式やその他のいくつかのエッジケースでうまく機能しません。

この機能をハンドルバーに含めるために再検討するか、少なくともハンドルバーコアがこの種の拡張をより適切にサポートできるかどうかを検討してください。

ビューレイヤーはカスタマイズ可能であるため、Ghostは非同期ヘルパーの明確で有効な（おそらく珍しい）ユースケースを示していると思います。

フロントエンドでは、Ghostのすべてのテンプレートがテーマによって提供されます。 テーマは、ハンドルバー、CSS、クライアントJSの非常に薄いレイヤーであり、アクセスできるデータは、事前に提供したデータのみです。 コントローラや動作変更ロジックにアクセスすることはできません。 これは非常に慎重です。

テーマAPIを拡張するために、テーマが利用したい追加のデータコレクションを定義するヘルパーの追加を開始したいと思います。 たとえば、次のようなものです。

{{#fetch tags}}
.. do something with the list of tags..
{{else}}
No tags available
{{/fetch}}

Ghostには、内部と外部の両方で利用できるJSONAPIがあります。 したがって、このフェッチクエリはブラウズタグ関数にマップされます。 すべてのエンドポイントに対してajax / httpを使用する必要はありません。代わりに、非同期ヘルパーがAPIからこのデータを内部的にフェッチし、通常どおり続行できます。

これが一般的なユースケースであるとは主張しません。標準のMVCモデルに違反することは認めますが、有効で有用であると思います。

@ErisDS素晴らしいニュースです！ そして私もその共通の問題については議論しませんが、それは役に立ちます。

この場合、現在非同期ヘルパーを使用している操作の多くは内部で同期されていますが、それらは約束として構造化されていることに注意してください。

詳細な例をあげると...

Ghostのすべてのデータは、内部APIを介してアクセスされます。 これには、設定などのグローバル情報が含まれます。 設定APIへのリクエストは、データベースにアクセスする前に、事前に入力されたメモリ内キャッシュにアクセスするため、実際には変数を返すだけですが、これを約束として構成することで、必要に応じてデータベースに簡単にアクセスできます。

また、すべての一貫性が確保されます。そうでない場合、設定APIは同期され、他のすべての内部データ要求は非同期になります。これは意味がありません。

約束を持ってすべてを構築することは、最初はかなり混乱する可能性があることを私は知っていますが、それは、一度それを手に入れなければ、あなたがどのように生きたかを理解できないことの1つです。 ES6でジェネレーターが登場すると、関数の非同期解決のサポートがJavaScriptに組み込まれます-そしてこの同様の問題： https ：//github.com/wycats/handlebars.js/issues/141は、ハンドルバーを作成するとよいと述べています歩留まりで作業します。

HTMLbarsの今後のリリースがこれにどのように影響するかはわかりませんが、少なくともさらなる議論が必要だと思います。

acl解決のヘルパーを作成しようとしているときに、別のユースケースに遭遇しました。 これは私のテンプレートにうまく適合します：

        {{#allowedTo 'edit' '/config'}}
            <li>
                <a href="/config">Config</a>
            </li>
        {{/allowedTo}}

ただし、node-aclの実際のisAllowedメソッドは非同期です（たとえば、データベースバックエンドを許可します）。

回避策は、すべてのユーザー権限を事前に取得することです（ allowedPermissions ）が、それはちょっとかゆいです

@kpdeckerこれらのユースケースについてさらに考えますか？

@ErisDS私はここでの欲求を理解していますが、これがコールバックまたは約束の形式で言語になることはないだろうと強く疑っています。 これは、APIの観点からきれいに行うのは非常に困難であり、それをサポートするためにテンプレートエンジンの大部分を効果的に書き直す必要があります。 上流のモデル/データソースがレンダリングサイクルに入る前に、これらすべてを処理することをお勧めします。

歩留まりのアイデアは興味深いものですが、誰かがそこで必要なものを調べたいと思ったら、それは素晴らしい研究プロジェクトになりますが、それに対するブラウザのサポートは私には非常に遠いようで、正直言って私は混乱していません私のプロジェクトのいずれかにまだこれらの機能のいずれか。

あなたが考慮したいと思うかもしれないちょうど私の「2」（まあ、カップル）セント：

• MVCは神聖なものではありません。 MVCと矛盾しているように見えるからといって、問題はありません。 代替案がMVCに厳密に従うよりも正味のプラスの利益をもたらさないかどうかを評価する必要があります。
• ビューが直接モデルではなくデータをコントローラーに要求する場合、それはとにかくMVCの違反ではありませんか？
• おそらく、ビューに必要なすべてのものを事前にコントローラーに知ってもらうことは、情報の複製であると主張することができます（つまり、「X、Y、Z、Wが必要です」という情報はビューとコントローラーで複製されます）。練習は、MVC、imoよりもはるかに重要なDRYの原則に違反している可能性があります。
• レンダリングされるビューに必要なモデルのみをロードするための非同期ヘルパーのパフォーマンスへの影響は、データベースからロードするデータを少なくすることで簡単に補うことができます。

あると便利な、より良い例を提供できるかもしれません。

私たちはモバイルアプリケーション向けにcordovaと多くの連携を行っており、多くの言語にローカライズする必要があります。 Cordovaは、日付、数値、通貨などのフォーマットを支援する関数を提供します。
問題は、それらすべてが非同期コールバックを必要とすることです。

例：

Handlebars.registerHelper('stringToNumber', function(string, type)
{
    type = type || 'decimal';
    navigator.globalization.stringToNumber(string, function(number)
    {
        return number;
    }, function()
    {
        return NaN;
    }, {
        type: type
    });
});

これは、imoがあれば素晴らしいでしょう。

npmでhandlebars -asyncパッケージを見つけました。 しかし、それは少し古く、現在のハンドルバーバージョンで動作するかどうかはわかりません。

私も約束のために似たようなものを書いたところです。 パッケージpromised-handlebarsを使用すると、ヘルパー内からPromiseを返すことができます。 プロジェクトの1つで使用する予定ですが、これまでのところ、実稼働環境では使用されていません。 しかし、いくつかのエッジケース（非同期ブロックヘルパー内から非同期ヘルパーを呼び出すなど）の単体テストがあり、それらはすべて緑色です...

@nknapp素晴らしいですね！ express-hbsは非同期をサポートしており、非同期はブロックヘルパーに対して機能しますが、非同期ヘルパーのネストは機能しません。したがって、これが機能することを非常に興味があります。つまり、express-hbs：+1：にはまだ希望があります。

@ErisDS 、そこに投稿するべきだと思いますか。 express-hbsが非同期ヘルパーをネストできないことに気づきませんでした。 私の主な焦点はexpressではなく、現在取り組んでいるREADMEジェネレーターです。 他の人に試してもらいたいと思います（約束されたハンドルバー）フィードバックをください。

有効なユースケースに追加するために、現在のロケールに基づいて変換DBから値をフェッチする必要がある場合はどうなりますか？

<div class="howItWorks">
    {{{i18nFetch id=how-it-works locale=locale}}}
</div>

さらに、次のような動的IDを使用してDBエントリからCMSブロックを追加するのはどうでしょうか。

<div class="searchCms">
    {{{cmsLoader 'search-{$term}' term=params.input defaultId='search-default'}}}
</div>

これは、サーバー側のレンダリング（つまり、 express-handlebarsを使用する）に特に役立ちます。

別のユースケースを次に示します。外部スキーマ定義を可能にするSwagger（ simple-swagger ）のドキュメントジェネレーターを作成しています。 スキーマが外部で定義されていることを認識し、そのスキーマが存在する提供されたURLに移動して取得し、そのデータを使用してハンドルバーテンプレートのその部分をレンダリングするハンドルバーヘルパーを作成したいと思います。 Handlebarsのコンパイルメソッドを呼び出す前にこのデータを取得する必要がある場合、構造が事前にわからないJSONドキュメントを再帰的に繰り返し、外部スキーマのすべてのインスタンスを見つけて取得し、それらをに挿入する必要があります。 JSON。

基本的に、JSONスキーマデータ（ json-schema.org ）をレンダリングするためにHandlebarsテンプレートが使用される場合は常に、非同期レンダリングメソッドが役立ちます。JSONスキーマでは常にスキーマのサブパーツを外部で定義できるためです。

@dwhiebは、ドキュメントジェネレータのbootprint - swaggerを見たことがありますか？ これはほとんどあなたが説明していることです（外部スキーマがまだ実装されていないことを除いて、それは素晴らしい機能になるでしょう）。 フィードバックがあれば、そこで問題を開いてください。

そして、 promised-handlebarsは非同期ヘルパーで非常にうまく機能すると思います。

ヘルパーでpromiseを使用できると便利なユースケースがあります。 ブログのHTMLを生成するためにハンドルバーを使用しています。 各記事の有効な構造化データを作成するには、記事の画像に使用しているディメンションを取得する必要があります。 今、私はこのようにやっています：

{{#imageSize post.frontMatter.previewImage}}
  <div itemprop="image" itemscope itemtype="https://schema.org/ImageObject">
    <meta itemprop="url" content="{{#staticResource ../post.frontMatter.previewImage}}{{/staticResource}}">
    <meta itemprop="width" content="{{width}}">
    <meta itemprop="height" content="{{height}}">
  </div>
{{/imageSize}}

imageSizeヘルパーはファイルを同期的に読み取るため機能しますが、理想的には非同期で読み取ることができるため、I / Oによってページのレンダリングが遅くなることはありません。 また、ファイルシステムではなく、URLの画像に対してこれを行うことは不可能です。

promised-handlebarsとexpress-hbsの使用について検討しますが、ヘルパー関数でpromiseを使用できることは、Handlebarsへの素晴らしい追加になると思います。

FWIW、私はHyperscript、 hyperscript-helpers 、ES7のasync/awaitを使用して多くの非同期HTMLレンダリングを行ってきましたが、それは本当に嬉しいことです。 しかしもちろん、そのソリューションはHTMLに対してのみ機能します。 ハンドルバーを使用した非同期ソリューションでは、他の種類のファイルを非同期で生成できます...ただし、HTMLの場合、私は決して振り返らないと思います。

express-hbsを試してみるつもりですが、2018年にはサポートしないのは奇妙なことだと思います。 非同期のものはビューの一部としてではなく、コントローラーと呼ばれる魔法のようなもので行われるべきであるという純粋な見方があることを私は知っています（MVCがどういうわけか間違いなく「正しい」かのように）-しかし、それは2つのキーについては少し近視眼的です理由

a）外部ライブラリ-ほとんどの人は今や完全にasync / awaitで書いています-私のコードでは、10個の関数のうち9個以上が非同期であると思います...場合によっては「念のため」です。 非同期機能をサポートしていないということは、すべての非同期ライブラリが突然完全にアクセスできなくなることを意味します

b）汎用コントローラー機能。 私はこのようなものを主張します：

    {{#query "select name, total from summary"}}
          <tr><td>{{this.name}}</td><td>{{this.total}}</td></tr>
    {{/query}}

は、変数に貼り付けてテンプレートに渡す特注のコントローラー機能を備えている場合と比較して、短く、クリーンで、保守が容易で、基本的に考えられるすべての点で優れています。テンプレートは、この関数を認識してアクセスする必要があります。