ホームページ  >  記事  >  ウェブフロントエンド  >  最新のフロントエンド フレームワークについての理解を話しましょう

最新のフロントエンド フレームワークについての理解を話しましょう

青灯夜游
青灯夜游オリジナル
2018-09-10 16:14:151369ブラウズ

この章では、最新のフロントエンド フレームワークについて説明します。必要な方は参考にしていただければ幸いです。

では、なぜ今、人々はさまざまなフレームワークを選択する必要があるのでしょうか?

実際、私たちが今フレームワークを選択する必要がある理由は、本質的に私たちが直面するニーズが変化したからです。インタラクティブな機能を持たずに情報を表示するだけのページを作成する場合、実際には今でもフレームワークを選択する必要はなく、数行の CSS と HTML を記述するだけでタスクを完了できることは誰もが理解しているはずです。 。したがって、私たちが直面する要件はより複雑になっているため、アプリケーションは実行時に何らかの対話を行う必要があることがよくあります。

太字で示されている 3 つの非常に重要な単語は、ランタイム と呼ばれます。最近のフロントエンド開発では、開発するアプリケーションの実行時に何らかの操作が必要になることがよくありますが、初期の頃、これらの操作はスライドやタブの切り替えドロップダウン メニューなどの単純な操作でした。これらの操作を jQuery で実装することに問題はありません。 。しかし、最新のフロントエンドに対する私たちの目標は、Web を使用してネイティブ アプリケーションを PK し、ネイティブと競合することです。

この時点で、jQuery を使用してアプリケーションを開発するとコードの保守が難しくなることがわかります。では、なぜ Vue、React などの最新のフレームワークを使用すると保守が容易になるのでしょうか。

Vue と jQuery の唯一の違いは、宣言的か命令的かです。

考えてみますが、DOM を操作するために jQuery を使用する目的は何でしょうか?これはビューをローカルで更新する、つまりローカルで再レンダリングすることです。

jQuery は DOM を操作するための命令型の方法であり、命令型の部分更新ビューですが、Vue、React、Angular などの最新の主流フレームワークはすべて宣言型であり、宣言型の部分更新ビューです。

宣言的な DOM 操作によりアプリケーションの保守が容易になるのはなぜですか?

この問題を理解するために、まず命令型と宣言型とは何かを簡単に紹介しましょう。

Imperative

Imperative は、jQuery と同様に、何かをしたいと思って、それを実行するだけです。たとえば、次のコード:

$('.box')
  .append(&#39;<p>Test</p>&#39;)
  .xxx()
  .yyy()
  .jjj()
  ...

Imperative は、何かを実行したい場合は、メソッドを直接呼び出して実行することを意味します。 . それは単純で、直接的で、粗雑です。

トグルエフェクトなどの非常に単純なシーンを想像してください。ボタンをクリックして色を切り替えます。

命令形で書きます。現在の色がそうである場合は、別の色に変更します。

よく考えてみると、実はステータスの判断とDOMの操作の2つの動作に分解できます。

では、宣言的とは何でしょうか? ?

Declarative

Declarative は、状態とビューの間のマッピング関係を記述し、そのマッピング関係を通じて DOM を操作すること、または具体的には、そのようなマッピング関係を使用して DOM ノードを生成することです。ページ。たとえば、Vue のテンプレートなどです。テンプレートの機能は、状態と DOM の間のマッピング関係を記述することです。

Vue でテンプレートを使用して同じシナリオを実装します。テンプレートを使用してマッピング関係を記述した後、ボタンをクリックして、要件を完了するために色変数を変更するだけです。

違いがわかりますか?

同じ要件を達成するには、慎重に考えて Vue を使用してください。論理的には、動作と状態は 1 つだけです。そして、jQuery は状態 + DOM 操作の 2 つの動作です。

それでは、なぜ宣言型アプローチによってアプリケーション コードの保守の複雑さを簡素化できるのでしょうか?

それは、状態の維持だけに集中できるからです。このように、アプリケーションが複雑になると、実際には私たちの考え方やコードの管理方法はステータスの観点からのみ行われ、すべての DOM 操作を気にする必要がなくなると言えます。メンテナンスが大幅に軽減されます。

DOM の操作方法に注意を払う必要はなくなりました。フレームワークが自動的に実行してくれるため、ステータスに注意するだけで済みます。

しかし、アプリケーションが特に複雑な場合は、状態維持だけに焦点を当てても、まだ難しいことがわかります。そのため、Vuex や Redux などの技術的なソリューションが必要になります。が現れてきました。

レンダリングとは何ですか?

前回の紹介の後、現代の主流フレームワークで解決すべき最も本質的な問題は依然としてレンダリングですが、異なるフレームワーク間では解決策が異なることがわかります。では、レンダリングとは何でしょうか?

さて、フロントエンドを開発する場合、アプリケーションは実行中にさまざまな対話を継続的に実行する必要があります。最新の主流フレームワークでは、アプリケーションの実行中、アプリケーションの内部状態が継続的に維持されることを意味します。変化します。

状態生成された DOM をページに挿入し、ユーザー インターフェイスに表示するこのプロセスはレンダリングと呼ばれます。

最新のフロントエンドフレームワークによるレンダリング処理

アプリケーションが実行されているとき、内部状態は変化し続けます。このとき、ユーザーページの特定のローカル領域は常に更新される必要があります。レンダリングされました。

再レンダリングするにはどうすればよいですか?

最も単純かつ粗雑な解決策は、フレームワークを使用しないプロジェクトでいくつかの単純な関数を作成するときに最も一般的に使用される方法でもありますが、状態を使用して新しい DOM を生成し、innerHTML を使用して古い DOM を置き換えることです。

私が作成した小さな関数ブロックにこの方法を使用しても問題はありません。関数にはほとんど DOM タグが含まれていないため、状態が変化すると、関数ブロックのほぼすべてのタグを変更する必要があるため、innerHTML を使用しても、パフォーマンスの無駄が多すぎますが、許容範囲内です。

しかし、フレームワークは良くありません。フレームワークを innerHTML に置き換えると、部分的に再レン​​ダリングされず、ページ全体が全体的に更新されます。では、フレームワークはどのようにして部分的な再レンダリングを実現できるのでしょうか。 -レンダリング?

この問題を解決するには、いくつかの技術的な解決策が必要です。それは VirtualDOM である可能性がありますが、必ずしも VirtualDOM である必要はありません。また、Angular のダーティ検出プロセスである場合もあれば、Vue1 のようなきめ細かいバインディングである場合もあります。 .0 これは、きめ細かいバインディングを使用して実現されます。

細粒度バインディングとは何ですか?

きめ細かいバインディングとは、特定の状態がページ上の特定のラベルにバインドされることを意味します。つまり、テンプレート内に特定の変数を使用するタグが 10 個ある場合、変数は 10 個の特定のタグにバインドされます。

React や Angular と比較すると、その粒度は比較的粗いため、実際にはどの状態変数が特定であるかがわかりません。そのため、ビューのどの部分を更新する必要があるかを知るには、比較が必要です。

Vue のきめ細かいバインディングは、状態が変化した瞬間にどの状態が変化したかを実際に認識しており、どの特定のタグがその状態を使用しているかも把握しているため、処理がはるかに簡単になり、このステータスにバインドされている特定のタグを直接更新することで目的を達成できます。ローカルアップデートの。

しかし、粒度が細かすぎるため、これを行うには実際には一定のコストがかかり、依存関係の追跡に一定のオーバーヘッドが発生します。したがって、Vue2.0 では、バインディングを中程度の粒度に調整するという妥協的な解決策を採用し始めました。

状態は特定のラベルではなく特定のコンポーネントに対応します。これには、コンポーネントの数が DOM 内の特定のラベルの数よりも大幅に減少するという利点があります。しかし、これにはもう 1 つの操作が必要です。ステータスが変化すると、コンポーネントにのみ通知が行われます。では、コンポーネントはどの DOM タグを更新するかをどのように認識するのでしょうか。 ?

答えは VirtualDOM です。

つまり、粒度を中程度に調整すると、コンポーネント内で VirtualDOM を使用して再レンダリングするための操作が 1 つ多く必要になります。

Vue は、変更検出 + VirtualDOM という 2 つの技術ソリューションを通じてフレームワークのパフォーマンスを巧みに向上させます。

つまり、Vue2.0 が VirtualDOM を導入したのは、VirtualDOM が優れているからではなく、VirtualDOM と変更検出を組み合わせることで、バインディングを中程度の粒度に調整して依存関係追跡のオーバーヘッド問題を解決できるためです。

変更検出に関しては、Vue が変更検出を実装する方法を紹介する特別な記事を書きました。ポータル。

つまり、変更検出の方法によって、フレームワークのレンダリング方法がある程度決まります。

VirtualDOM の実装原理について PPT を書きましたので、興味があればポータルをご覧ください。

もう 1 つはテンプレートのコンパイルです。実際、テンプレートのコンパイルについてはあまり説明しませんでしたが、テンプレートの機能は、状態と DOM の間のマッピング関係を記述することです。このレンダリング関数を実行すると、VirtualDOM で提供される VNode を取得できます。実際、以前に VirtualDOM の原理を紹介した PPT をご覧になった方は、VirtualDOM がノードを比較していることが実際には VNode を比較していることがわかります。テンプレートコンパイルポータルの実装原理を紹介する特別記事を書きました。

まとめ

現在のフロントエンドは少し性急だと個人的に感じています。多くの人が新しいものを追い求め、今日リリースされる新機能、明日リリースされる新しいフレームワークなどに毎日注目しています。それらはありますが、新しいものを追いながら、その本質を見ていきたいと思っています。すべての技術的解決策の最終的な目標は、まず問題があり、その後に解決策が存在します。解決策は完全ではない可能性があります。では、それらの間にはどのような利点と欠点があるのでしょうか。問題を解決する際に、それぞれがどのようなトレードオフとトレードオフを行ったのでしょうか?表面に惑わされず、現象を見抜いて本質を見なければなりません。




以上が最新のフロントエンド フレームワークについての理解を話しましょうの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。

声明:
この記事の内容はネチズンが自主的に寄稿したものであり、著作権は原著者に帰属します。このサイトは、それに相当する法的責任を負いません。盗作または侵害の疑いのあるコンテンツを見つけた場合は、admin@php.cn までご連絡ください。