Mustache.js: オプションの追加：不明な変数に関する警告

ローカルで開発している間、他のフレームワークからこの機能が大好きなので、私から+1してください！ パフォーマンスへの影響を最小限に抑えるか、まったく影響を与えないことが重要だと思います。 コアをそのままにしておくこともできるのでしょうか？ たとえば、開発中にこの種の動作を有効にするために、いくつかの内部メソッドをオーバーライドします。

たぶんmustache.dev.jsビルドが使用しているmustache.jsとチェック・ロジックを含む関数のオーバーライドを？

ハードエラーが望ましいので、たとえば、Expressで使用すると、エンドユーザーが誤ってレンダリングされたページを表示しているときにログだけでなく500応答になります（欠落している方法によっては、非常に誤ってレンダリングされる可能性があります）。変数が使用されることになっていた）; これは、500ページがどれだけ優れているかと、誤ってレンダリングされたページがアプリケーションの機能にどれほど悪いかによっては、ローカル開発よりも本番環境でさらに役立つ可能性があります。 セクションを使用すると、直接使用するためのハードエラーがあっても、テンプレートが欠落している変数を無視できる可能性があります。 また、問題をログに記録する必要のある高レベルの使用は、ログシステムの制御下にあるため、たとえば、Mustacheの内部警告メカニズムがテストランナーからの出力を壊してしまうことなどについて心配する必要はありません。

https://github.com/ScottFreeCode/mustache.jsに実用的なプロトタイプがあり

うーん、オブジェクトの存在をif （ {{#thing}} ）として使用すると、エラーがスローされますか？ （これはかなり一般的だと思います）

または、変数の実際のレンダリング（ {{ id }} ）のみがエラーを発生させますか？ 何を考えていたのですか？

編集：面倒にならない場合に備えて、メジャーでデフォルトで有効にするために+1する非常にクールな機能。

私の考えでは、最初はエラーであり、2番目は「警告」である必要があります。
どちらの場合も、欠測値があることを知りたいと思います。

2番目のケースでは、技術的には壊れないかもしれませんが、ページに大きな影響を与える可能性があります。

また、逆の方法もいいでしょう。未使用の変数…しかし、それはもっと大きな影響を与えると思います！ ：NS

2016年11月8日、14：19で、デビッド・ダ・シルバの[email protected]は書きました：

うーん、オブジェクトの存在をif（{{＃thing}}）として使用すると、エラーがスローされますか？ （これはかなり一般的だと思います）

または、変数（{{id}}）の実際のレンダリングのみでエラーが発生しますか？ 何を考えていたのですか？

—
スレッドを作成したため、これを受け取っています。
このメールに直接返信するか、GitHub https://github.com/janl/mustache.js/issues/599#issuecomment -259133973で表示するか、スレッドをミュートしてくださいhttps://github.com/notifications/unsubscribe-auth/ AJ8FmSptdhysYrQpg1ODkIrm12A_TXcYks5q8HbbgaJpZM4J8lKe。

私の考えでは、最初はエラーであり、2番目は「警告」である必要があります。
どちらの場合も、欠測値があることを知りたいと思います。

@MatthijsZwなるほど。 プロパティのnull値を格納できることを思い出しました。これは良いことであり、したがって例外は発生しません。 （特にif場合はこれに言及します）

編集：私の現在の立場は、両方でErrを好むということです。 私は一貫した動作を好みます。空の欠測値にはnullの使用を強制しますが、これは望ましいと思います。

また、逆の方法もいいでしょう。未使用の変数…しかし、それはもっと大きな影響を与えると思います！ ：NS

テンプレートが期待しているデータのスキーマをなんとかして取得し、それを使用してGraphQLクエリなどを生成するのはクールだと思います。

さらに考えてみると、ここでの問題の一部は、欠落しているデータが無効であるということだと思います。なぜなら、テンプレートがそのデータを期待している場合に限ります。 したがって、テンプレートが単純に表示するだけの欠落データは、そのロジックでは常に無効ですが、テンプレートは、特定のデータが利用可能であると期待し、ある種の真/偽フラグとして分岐する可能性があると考えられます（つまり、欠落しているほど偽ではなく、したがってその期待を満たしていない場合は無効です）が、別の場合は、データが利用可能かどうかを期待し、利用可能かどうかで分岐する可能性があります（この場合、無効になることはありません）。

その観点では、これを制御するためにnullを使用することは、私にはあまり意味がありません。

• データが間違っている場合（期待に応えていない場合）、間違ったデータを処理することに関するテンプレートの動作を制御するために、間違ったデータをどのように期待できますか？
• とにかく、期待は本当にテンプレートにあります。
• nullは、データを期待し、データが欠落していることは無効であると見なす真実性の分岐の誤った値である可能性がありますが、それでも、データが提供されたかどうかを正確に分岐する必要があります。データが入力されない可能性があることを期待します（SQLなどの欠落データにnullを使用するソースからのものでない限り、 nullでも入力されません）。 nullを欠落しているものとして扱うか、データソースに基づいて構成可能にする必要があります）。

テンプレート側の期待が異なるため、必要なのは2種類のブランチです。 私の知る限り、言語に依存しないMustache仕様では、欠測データがエラーであるかどうかの構成が可能ですが（必須ではありません）、別の種類のブランチには何もありません。この点で異なります。 うーん...

反対に、私は現在、無関係/余剰/未使用のデータは実際にはデータが無効であるという問題ではなく、アプリケーション/データ/でそのデータを使用しない場合はテンプレートが無効であるという問題であると考えています。モデルはそれが使用されることを期待しています。 つまり、一部のものが潜在的に使用可能であるが、テンプレートがそれが関連するかどうかを判断できる場合、テンプレートがそのものを印刷するかどうかは問題ではありませんが、一部のものが本当にユーザーに表示される必要がある場合、テンプレートは表示されません。エラーだと表示します。 一種の逆転として、期待値はテンプレートの外側（モデル内？）にあり、その期待値を満たさないことの無効性はテンプレートにあります。 おそらくそれとは別に取り組むのが最善だと思います。

以上のことは、強い意見が弱いと思います。

null値を存在しない値として解釈するIMOは間違っています。

{ name: null }

そのオブジェクトには、偽の値を持つnameプロパティがあるため、無効と見なされるべきではなく、スローする理由にもなりません。

より適切なチェックは、 mustache.hasProperty（）のように、要求されたプロパティが定義されているかどうかをチェックすることです。

しかし、別の方法では、データが利用できる場合とできない場合があり、利用できるかどうかで分岐する場合があります（この場合、データが無効になることはありません）。

私が伝えようとしていたのは、キーX （たとえば、 {{#X}} ）に応じて分岐する場合、提供されるデータには、キーX値が含まれている必要があるということです。偽の値ですが、 undefinedはありません。

• null 、「ええ、私は価値がないことを知っています。私は価値がないことを明示的にマークしています」を意味します。
• undefinedほとんどの場合、キーXが定義されていないことを意味します（ undefined値でキーを定義する場合は、 nullを使用する方がよいでしょう） 。 また、キーが定義されていない場合は、データの宣言が「怠惰」である（たとえば、オブジェクト参照が不足しているときにnullを使用しない）か、人為的エラー（タイプミス、スリップ、混乱）が原因です。

したがって、この場合、エラーをスローすることには利点があります。 （値がundefinedキーで分岐しようとしています）

もう1つのケースでは、 undefinedまたはnullいずれかをレンダリングしようとしていますが、そのユースケースがあるかどうかはわかりません。 たぶん、その1つでもエラー。

SQLなどの欠落データにnullを使用するソースからのものでない限り

Afaik、Mustacheの哲学は、モデルをそのまま使用するのではなく、モデルから「ビュー」を生成することです。 プロバイダーが何らかの理由で追加しない場合に備えて、 null追加できます。

私は現在、無関係/余剰/未使用のデータは実際にはデータが無効であるという問題ではなく、アプリケーション/データ/モデルが期待するときにそのデータを使用しない場合はテンプレートが無効であるという問題であると考えています利用される

うーん、提供されたすべてのデータを使用しないのはかなり一般的だと思います。 私が提案したGraphQLクエリ生成のように、主にツールの優れた機能のためにアイデアを投入しました。

本当にユーザーに表示する必要があるものがある場合、テンプレートに表示されない場合はエラーです

しかし、誰が/何が「本当にユーザーに表示する必要があるもの」を決定するのでしょうか。 私が推測しているテンプレートライター？ ビュー内のすべてのデータを使用するようにユーザーに強制すると、レンダリングするテンプレートごとに調整されたビューを生成するように強制されます。

注：私のユースケースは、分岐なしの手動セットアップでした。

「他の人」に手動でデータ（イベント）を作成してもらいました。その場合、すべてのフィールドに入力したか、変数名にタイプミスをしたかを確認する方法がありませんでした。

私のテンプレートは「{{event.date}}の{{event.name}}」と言うでしょう。 その場合、値が欠落していると恐ろしいページが作成されます。
すべてのフィールドが必須だったため、{{event.date}}を表示しないロジックを追加しても意味がありません。

この場合、「使用されていない」変数も知っておくと便利です。タイプミスや、ページに「魔法のように」表示されると考えて追加したアイテムを再確認してください:)

このユースケースはどういうわけかMustacheのイデオロギーに違反していると思いますが、それは実際のシナリオです。
また、両方の状況（欠落値+未使用の値）で警告が生成されると便利です。

2016年11月9日、10時53分で、デビッド・ダ・シルバの[email protected]は書きました：

しかし、別の方法では、データが利用できる場合とできない場合があり、利用できるかどうかで分岐する場合があります（この場合、データが無効になることはありません）。

私が伝えようとしていたのは、キーXに応じて分岐する場合（{{#X}}など）、提供されるデータには、キーXの値が真または偽の値である必要がありますが、間違いなく未定義ではないということです。

nullは、「ええ、私は価値がないことを知っています。私は価値がないことを明示的にマークしています」を意味します。
undefinedは、ほとんどの場合、キーXが定義されていないことを意味します（undefinedの値でキーを定義する場合は、nullを使用する方がよいでしょう）。 また、キーが定義されていない場合は、データを「遅延」宣言している（たとえば、オブジェクト参照が不足しているときにnullを使用していない）か、人為的エラー（タイプミス、スリップ、混乱）が原因です。
したがって、この場合、エラーをスローすることには利点があります。 （値が未定義のキーで分岐しようとしています）

一方、未定義またはnullのいずれかをレンダリングしようとすると、そのユースケースがあるかどうかがわかりません。 たぶん、その1つでもエラー。

SQLなどの欠落データにnullを使用するソースからのものでない限り

Afaik、Mustacheの哲学は、モデルをそのまま使用するのではなく、モデルから「ビュー」を生成することです。 プロバイダーが何らかの理由で追加しない場合に備えて、nullを追加できます。

私は現在、無関係/余剰/未使用のデータは実際にはデータが無効であるという問題ではなく、アプリケーション/データ/モデルが期待するときにそのデータを使用しない場合はテンプレートが無効であるという問題であると考えています利用される

うーん、提供されたすべてのデータを使用しないのはかなり一般的だと思います。 私が提案したGraphQLクエリ生成のように、主にツールの優れた機能のためにアイデアを投入しました。

本当にユーザーに表示する必要があるものがある場合、テンプレートに表示されない場合はエラーです

しかし、誰が/何が「本当にユーザーに表示する必要があるもの」を決定するのでしょうか。 私が推測しているテンプレートライター？ ビュー内のすべてのデータを使用するようにユーザーに強制すると、レンダリングするテンプレートごとに調整されたビューを生成するように強制されます。

—
あなたが言及されたのであなたはこれを受け取っています。
このメールに直接返信するか、GitHub https://github.com/janl/mustache.js/issues/599#issuecomment -259374603で表​​示するか、スレッドhttps://github.com/notifications/unsubscribe-auth/をミュートします

このユースケースはどういうわけかMustacheのイデオロギーに違反していると思いますが、それは実際のシナリオです。 また、両方の状況（欠落値+未使用の値）で警告が生成されると便利です。

どちらも実行可能のようです。 CIに役立つ可能性があります。

デバッグのために、パラメーターをビューに直接表示したいと思います。

私のユースケースは少し異なります。Mustacheを使用して、Gulpを使用してTerraformテンプレートを変換します。 変数が欠落していると、特に自由形式の文字列に置き換えるときに、インスタンスが正しく起動しない可能性があります。 私はこの機能を取得するための簡単なモンキーパッチを思いついたが、それはほとんど理想的ではない：

var mustache = require("mustache");

var errors = [];
var lookup = mustache.Context.prototype.lookup;

mustache.Context.prototype.lookup = function(name) {
    var value = lookup.bind(this)(name);

    if (value === undefined) {
        console.error("Unknown symbol", name);
        errors.push(name);
    }

    return value;
}

var render = mustache.render;

mustache.render = function(template, view, partials) {
    var result = render.bind(this)(template, view, partials);

    if (errors.length > 0) {
        throw {message: "Unknown symbols: " + errors.join(", ")};
    }

    return result;
}

ノート：

• 行番号や完全修飾記号名は表示されません
• マルチスレッド環境で作業している場合は、おそらく完全に安全ではありません

しかし、それは私の目的にはうまく機能し、必要に応じて誰かがそれを適応させることができると確信しています。

あらゆる種類の構成管理環境でテンプレートエンジンとして口ひげを使用するには、変数が欠落している場合にハードエラーが必要です。 @steverukutsに似たユースケースが

@stefanegを書いた数か月後、実際、TerraformがJSON形式で記述された構成をサポートしていることを発見したので、Mustacheを使用する代わりにこれを使用します。 これははるかに優れており、よりプログラム可能です。 これに対するMustacheの使用は非推奨になり、デプロイメントパイプラインの次のリビジョンで削除される予定です。

Kubernetesのデプロイドキュメントを見ると、これらはYAMLファイルであることがわかります。 ほとんどのプログラミング言語にはYAMLの読み取りと書き込みが可能なライブラリがあるため、代わりにこれを行うことをお勧めします。 私の実験から、機械可読形式を操作しようとすると、ほとんどの場合、Mustacheよりも優れたオプションがあることがわかりました。

注意：Mustacheはもう何にも使用していませんが、これは有効な機能リクエストであると感じています。

解決策は、同じ構文をサポートするハンドルバーを使用することです。また、このユースケースで必要とされる厳密なオプションもあります。

@steverukutsサポートする必要のある事前正しいです。 オープンエンドの構成ツールの場合、柔軟性が非常に速くなるため、テンプレートを作成する必要があります。 任意の場所に任意の値を挿入することをサポートするツールを書いてみてください...すぐにテンプレートエンジンができました。

仕事では、ここ数年、Kubernetesリソースを構成するためにkontemplateを使用しています。 これは基本的にgoテンプレートエンジンであり、そのプロジェクトの小枝やカスタム機能からいくつかの便利な機能を備えています。 たとえば、ヘルムよりも軽量なアプローチとして作成されています。

上記の議論に関連して; また、未知の変数で爆発します。

解決策は、同じ構文をサポートするハンドルバーを使用することです。また、このユースケースで必要とされる厳密なオプションもあります。

この問題により、ハンドルバーも使用せざるを得なくなりました。 これが口ひげでサポートされていないのは残念です。