フロントエンドテンプレートエンジンの問題の詳細な説明-htmlチュートリアル-php.cn

フロントエンドテンプレートエンジンは、開発中に透過的である必要があります

透過性とは、開発環境をセットアップした後、追加のコマンドを実行することなく、コードを記述してブラウザを更新して最新の効果を確認できることを意味します。または待機中のプロセス。

そのため、コンパイルプロセスに依存するすべてのテンプレートエンジンはフロントエンドでの使用には適していません。コンパイルはテンプレートエンジンの機能の 1 つであり、使用の前提条件ではありません。

より厳密に言えば、FileWatch やその他の手段を使用してください。ファイルの変更を検出して自動的にコンパイルすることも、追加の待機が発生するため、私の検討の範囲外です。このことから、フロントエンドのテンプレートエンジンには解析して使用できる機能が必要であると推測できます。純粋なフロントエンド環境。

フロントエンドのテンプレートエンジンは、優れたランタイムデバッグ機能を備えている必要があります

ユーザーの行動の不確実性、実行環境の不確実性、さまざまなサードパーティスクリプトの影響などにより、フロントエンドのテンプレートエンジンの実行は困難です完全なエラー処理と追跡を実現するには、フロントエンドがオンラインで問題のトラブルシューティングを直接行う必要があるという事実にもつながりますそして、問題がテンプレートエンジンレベルで発生した場合、テンプレートエンジンは優れたデバッグ機能を提供する必要があります

一般的につまり、コンパイル後に生成される関数のデバッグ能力は、手動で作成された元のテンプレートフラグメントよりも弱いです。これは、自動生成された関数は基本的に読み取り不可能であり、ブレークポイントを追跡できないためです

したがって、この時点で、フロントエンドで使用するテンプレートエンジンは、特定の状況下では、「コンパイルされた関数を実行して HTML を取得する」モードが「元のテンプレートを解析してから HTML を取得する関数を実行する」モードに戻ります。つまり、2 つのモード間の切り替えをサポートする必要があります

または。さらに良いのは、強力なフロントエンドテンプレートエンジンがコンパイルすることです。生成された関数は、ソースマップまたはその他のカスタマイズされた手段を使用して、元のテンプレートフラグメントに直接マッピングし直すことができます。ただし、現在、フロントエンドテンプレートエンジンはこの関数を実装する必要があります。ファイルのマージに優しい HTTP/2 では、ファイルのマージは依然としてフロントエンドのパフォーマンス最適化において重要な手段であり、コンパイル機能を提供するテンプレートエンジンでマージする必要があります。コンパイルを使用してテンプレートを JavaScript に変換し、JavaScript に基づいてファイルをマージできます

ただし、前述のデバッグ機能などの理由で元のテンプレートのフラグメントを保持したい場合は、テンプレートエンジン自体がサポートする必要があります。テンプレートフラグメントを 1 つのファイルに結合する

大入力文字列をテンプレートとして解析することのみをサポートする一部のエンジンには、本質的に文字列全体を複数のテンプレートフラグメントに分割することができないため、テンプレートでのファイルの結合をサポートできません。フラグメントレベル

ファイルのマージのサポートを実装する必要があります。最良の方法は、「フラグメント」に基づいてテンプレートの構文を作成することです

フロントエンドテンプレートエンジンは、XSS を防ぐ役割を担う必要があります

セキュリティの観点から、フロントエンドは XSS を制御することが厳密に要求されます

フロントエンドで XSS を防ぐより適切な方法は、「デフォルトエスケープ」のホワイトリスト戦略を使用することです

これに基づいて、合理的なテンプレートエンジンは

必須です

デフォルトのエスケープ、つまりすべてのデータのサポート出力はデフォルトでエスケープロジックによって処理され、キーシンボルは対応する HTML エンティティシンボルに変換され、ルートから XSS の侵入パスが排除されます。もちろん、すべてのコンテンツをエスケープする必要はありません。システムには必然的にいくつかのエラーが発生するため、エスケープされていない出力を生成するには特定の構文がサポートされている必要があります。ただし、エスケープされていない出力は特殊なケースであり、エスケープされた出力である必要があることに常に注意してください。デフォルトでは

フロントエンドテンプレートエンジンはフラグメントの再利用をサポートする必要があります

これはフロントエンドテンプレートエンジンの要件ではありません。実際、Velocity などのテンプレートエンジンはフラグメントの再利用をサポートする必要があります。、Smarty などはすべてこの機能を備えています。いわゆるフラグメントの再利用には、次の階層アプリケーションが含まれている必要があります:

フラグメントは別の場所に導入でき、これはどこでも使用される変数の効果と同等です

フラグメントを導入すると、そこに別のデータを渡すことができ、どこでも関数が使われているのと同等になります

を使用する効果フラグメントは外部から置き換えることができますが、フラグメントが外部に提供されていない場合、デザインモードのストラテジーモードと同様に、デフォルトのコンテンツが維持されます

1番目と2番目のポイントを満たすテンプレートエンジンはほとんどなく、3番目のポイントを満たすフロントエンドテンプレートエンジンはまれであり、バック-end Razor、Smarty などはすべてこの機能を持っています

フロントエンドのテンプレートエンジンはデータ出力中の処理をサポートする必要があります
いわゆるデータ出力中の処理とは、データの一部が追加の変換を受ける必要がある場合を指します。最も一般的なのは文字列のトリム操作であり、マークダウン変換などのより技術的な操作です。確かに、データをテンプレートエンジンに渡す前に JavaScript ロジックを通じてデータ変換を実行できますが、これによりエラーが発生します。醜くて冗長なコードが多く、ロジック自体の再利用性にも悪影響を及ぼします

通常、テンプレートエンジンは、bash のパイプラインのロジックと同様に、フィルターの形式でデータに対して追加の処理を実行します。フィルタの実装と登録にもさまざまな設計があります。たとえば、mustache は実際にフィルタそのものを登録しますが、設計が異なると考慮すべき点も異なります。誰が悪い

しかし、テンプレートエンジンがデータ出力処理をサポートすると、コーディングプロセスで新たな問題が発生します。つまり、どのデータ処理をテンプレートエンジンのフィルターで実装するか、どのデータをどのデータをフィルターで実装するかという問題が発生します。テンプレートエンジンに渡される前に独自のロジックを実行します。このトピックは長い説明ですので、現在のトピックに関係がない場合は、スキップしてください。たとえば、EmberJS などの開発プロセスでは、多くのデータが動的データをサポートする必要があります。 Angular には Computed Property などの概念があり、Angular にも同様のものがあります。Backbone は Model の get メソッドをオーバーライドすることで偽装して実装できます

ES5 は言語レベルでゲッターサポートを直接提供しますが、ほとんどの場合、フロントエンドで開発します。シナリオでは、この言語機能はまだ使用されていませんが、動的データは何らかのオブジェクトの get メソッドにカプセル化されますデータを HTML フラグメントに変換するときに、テンプレートエンジンもこれに注意する必要があります。これらの動的に計算されたデータのサポート

より明確に言うと、テンプレートエンジンはプレーンオブジェクトを入力として受け入れるだけでなく、get メソッドを使用して動的データをよりオープンに受け入れる必要があります

より合理的なロジックは、オブジェクトがget メソッドがあり (テンプレートエンジンがこのインターフェイスを決定します)、その他の場合、入力オブジェクトは純粋なオブジェクト (プレーンオブジェクト) とみなされ、標準の属性が使用されます

。フロントエンドテンプレートエンジンは非同期プロセスと密接に統合する必要があります

非常に一般的な例としては、グローバルに使用される定数を保存する AMD モジュールがあり、テンプレートエンジンがこれらの定数を使用する必要があることが挙げられます。もちろん、テンプレートエンジンを使用する前に JavaScript にこのモジュールを非同期で取得させ、定数をデータとしてテンプレートエンジンに渡すこともできますが、これは強迫性障害からのビジネスとビューを結び付ける方法です。これが美しいデザインだとは思わないでください。そのため、現在のように文字列を直接返すのではなく、テンプレート自体の出力が非同期メソッドになることを願っています

テンプレートの非同期への依存を分析してください操作と文字列全体の結合ロジックが複数の非同期に中断されます

非同期には待機が必要ですが、その待機は不明ですパフォーマンスの観点から、1 つのセクションを完了するためにストリームスタイルの出力を考慮する必要がありますか? 1 つのセクションを提供しますか?
- には、いくつかのタイプの非同期ロジックを修正するか、複雑さと実用性のバランスをとるために Promise に基づいてカスタマイズされた非同期ロジックをサポートします
- これまでのところ、私はその方法を完全には理解していませんが、テンプレートと非同期を組み合わせるインターフェイスについては、私にできることは何もありません
- フロントエンドテンプレートエンジンは、さまざまな開発モデルをサポートする必要があります
- これまでのところ、フロントエンドは、以下のようなさまざまな開発モデルがあります:
最も一般的な HTML ページは、DOMContentLoaded などのイベントを使用してロジックを追加します。特定のインタラクションの下でページを部分的に更新します。

単一ページ開発には従来の MVC モデルを使用します。

データをコアとしてMVVM手法を使用し、データとビューの方向をバインディングして開発
- 不変データに基づくデータ比較 Diff-to-DOM更新の開発(仮想DOMの導入を含む場合があります)
- テンプレートエンジンにとって、非常に多くの異なるモード、特に双方向バインディングのサポートをサポートすることは非常に大きな課題です。これまでのところ、双方向バインディングをサポートするほとんどすべての開発フレームワークには、専用のテンプレートエンジンが付属しています。これは、双方向バインディングには、テンプレートに対して次の 2 つの主要な要件があるためです。テンプレートには「データの依存関係」
- のメタ情報があり、
- 全体を更新しなくても、データ変更エンジンがテンプレートのどの部分であるかを知ることができます。異なるものを比較する方法はありませんフロントエンド開発モデルの包括的なサポート
フロントエンドテンプレートエンジンは、インスタンス
- 大規模なフロントエンドプロジェクト、特に単一ページのプロジェクトでは、まったく未知の数のテンプレートフラグメントが同時に存在することになります。これらのフラグメントに名前が付いている場合 (再利用を考慮して)、Name が発生する可能性が高くなります。紛争
  
  同じレベルのロジック (たとえば、全員がビジネス層のコードで作業している、または全員が制御層のコードで作業している) の場合、名前の競合はいくつかの開発規約によって解決できます。しかし、異なるレイヤー間では、カプセル化の要件により、内部でのみ使用される一部のフラグメントの名前を外部は知ることができません。このとき、残念ながら名前が他のレイヤーと競合する場合、そのような問題はさらに厄介になる可能性があります。追跡するのは簡単ではなく、多くのエネルギーと時間の無駄につながることがよくあります
  
  したがって、優れたテンプレートエンジンには複数のインスタンスが必要であり、そのような予測不可能な競合を避けるために異なるインスタンスは相互に分離されている必要があります
  
  このトピックをさらに詳しく説明すると、異なるレイヤー間の競合をなくすだけでは不十分であることがわかります。また、異なるテンプレートインスタンス間でいくつかの固定関数を開く必要もあります。は共有されるため、テンプレートエンジンの各インスタンス間の関係は依存関係の組み合わせになりますが、基本的なカプセル化と分離が行われます。