フロントエンド テンプレート エンジンの問題の詳細な説明

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

必須です

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

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

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

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

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

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

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

1. フロントエンドのテンプレート エンジンはデータ出力中の処理をサポートする必要があります

2. いわゆるデータ出力中の処理とは、データの一部が追加の変換を受ける必要がある場合を指します。最も一般的なのは文字列のトリム操作であり、マークダウン変換などのより技術的な操作です。確かに、データをテンプレート エンジンに渡す前に 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 つの主要な要件があるためです。テンプレートには「データの依存関係」

   • のメタ情報があり、

   • 全体を更新しなくても、データ変更エンジンがテンプレートのどの部分であるかを知ることができます。異なるものを比較する方法はありません フロントエンド開発モデルの包括的なサポート
   テンプレート エンジン自体の実装から、1 つの方法は、他のフレームワークが合理的に処理できるようにテンプレート解析後に AST のような構造を直接公開することです。時間はテンプレート関数の部分的な更新を提供します (前述のテンプレート フラグメントと一緒に考慮することもできます)。ただし、パフォーマンス上の理由から、ほとんどのテンプレート エンジンは AST のような構文構造を解析しません

   
   フロントエンド テンプレート エンジンは、インスタンス

   • 大規模なフロントエンド プロジェクト、特に単一ページのプロジェクトでは、まったく未知の数のテンプレート フラグメントが同時に存在することになります。これらのフラグメントに名前が付いている場合 (再利用を考慮して)、Name が発生する可能性が高くなります。紛争

     同じレベルのロジック (たとえば、全員がビジネス層のコードで作業している、または全員が制御層のコードで作業している) の場合、名前の競合はいくつかの開発規約によって解決できます。しかし、異なるレイヤー間では、カプセル化の要件により、内部でのみ使用される一部のフラグメントの名前を外部は知ることができません。このとき、残念ながら名前が他のレイヤーと競合する場合、そのような問題はさらに厄介になる可能性があります。追跡するのは簡単ではなく、多くのエネルギーと時間の無駄につながることがよくあります

     したがって、優れたテンプレート エンジンには複数のインスタンスが必要であり、そのような予測不可能な競合を避けるために異なるインスタンスは相互に分離されている必要があります

     このトピックをさらに詳しく説明すると、異なるレイヤー間の競合をなくすだけでは不十分であることがわかります。また、異なるテンプレート インスタンス間でいくつかの固定関数を開く必要もあります。は共有されるため、テンプレート エンジンの各インスタンス間の関係は依存関係の組み合わせになりますが、基本的なカプセル化と分離が行われます。

以上がフロントエンド テンプレート エンジンの問題の詳細な説明の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。