フロントエンドコンポーネント化の基礎知識を詳しく解説

フロントエンドアーキテクチャに関して言えば、実は最もホットなトピックが 2 つあります。1 つはコンポーネント化、もう 1 つはアーキテクチャモデルです。コンポーネント化の概念は、HTML タグを拡張する方法の研究から始まり、最終的にはフロントエンドアーキテクチャシステムへと進化しました。そして、その最も重要な機能は、フロントエンドコードの再利用性を向上させることです。

アーキテクチャパターンは、 MVC 、 MVVMなど、誰もが特によく知っている設計パターンです。このトピックでは、主にフロントエンドとデータロジック層間の相互作用について説明します。

したがって、フロントエンドアーキテクチャではコンポーネント化が最優先事項であると言えます。実際のエンジニアリングでは、アーキテクチャモードよりもコンポーネント化が重要になることがよくあります。コンポーネント化はフロントエンドチームのコード再利用率を直接決定し、優れたコンポーネント化システムはフロントエンドチームのコード再利用率を向上させ、それによってチーム全体の効率を向上させるのに役立ちます。

再利用率が高まるため、全員が繰り返し書くコード量が減り、効率が上がり、チームメンバーにかかる心理的・精神的な負担が大幅に軽減されます。

したがって、コンポーネント化を学ぶことは非常に重要です。

ここでは、コンポーネント化とは何か、そしてコンポーネントの基本的な構成要素を理解することから始めます。

コンポーネントの基本概念

コンポーネントはモジュールとオブジェクトに分かれています。コンポーネントは UI と深く関係しているので、ある意味では特別なモジュールや特別なオブジェクトと考えることができます。

コンポーネント化は對象と模塊両方である

コンポーネント化の特徴は、ツリー構造を利用して組み合わせることができ、ある程度のテンプレート構成機能を備えていることです。これが私たちのコンポーネントの基本的なコンセプトです。

オブジェクトとコンポーネントの違い

まず、 3 つの主要な要素を持つオブジェクトを見てみましょう。

プロパティ
方法
継承

JavaScript の通常のオブジェクトは、そのプロパティ、メソッド、継承関係によって記述できます。ここでの継承は、JavaScript のプロトタイプ継承を使用します。

ここで言う「通常のオブジェクト」には、複雑な関数オブジェクトやその他の特殊なオブジェクトは含まれません。JavaScript では、プロパティとメソッドが統合されています。

コンポーネントと比較すると、コンポーネントにはより豊富なセマンティック要素が含まれています。コンポーネント内の要素は次のとおりです。

プロパティ
方法
継承
属性
構成と状態
イベント
ライフサイクル
子供たち

PropertiesとAttribute英語ではまったく異なる意味を持ちますが、多くの場合「プロパティ」と翻訳されます。両方の単語が出現する場合、 Attribute 「特性」に翻訳され、 Properties 「属性」に翻訳されます。これら 2 つの要素をどのように区別するのでしょうか?これについては、この記事の後半で詳しく説明します。

次はコンポーネントのConfigです。これはコンポーネントの構成です。コンストラクターでオブジェクトを作成するときに、 Configよく使用します。このコンストラクターに渡すパラメーターは「 Config 」と呼ばれます。

コンポーネントにもstateがあります。ユーザーが操作したり、何らかのメソッドが呼び出されたりすると、 stateが変化します。これはコンポーネントの状態であり、いくつかの動作によって変化します。 stateとproperties 、 attributes 、およびconfig 、よく知られているか、同じである可能性があります。

eventは「出来事」の意識であり、イベントはコンポーネントによって外部に伝達されます。私たちのコンポーネントは主に UI のようなものを記述するために使用され、基本的に何らかのインタラクションを実装するためにこの種のイベントを持ちます。

各コンポーネントにはlifecycleがあり、これについてはこの記事の後半で詳しく説明します。

childrenコンポーネントの非常に重要な部分です。 childrenコンポーネントの必須条件でもあります。 childrenコンポーネントがないとツリー構造を形成することができず、インターフェースを記述する能力が大幅に低下するからです。

以前は、事前に記述された UI コンポーネントをページにドラッグしてシステムインターフェイスを構築できる、人気のドラッグアンドドロップシステムがいくつかありました。しかし、後になって、特定の領域でドラッグアンドドロップできることに加えて、自動ソートやコンポーネントのネストなどの機能要件も必要であることがわかりました。このとき、コンポーネント間にツリー構造がないと動作しません。

最後に、コンポーネントはオブジェクトに基づいて意味的に関連する多くの概念を追加するため、コンポーネントは UI を記述するのに非常に適した概念になります。

成分

図を使ってコンポーネントをより深く理解してみましょう。

コンポーネントの変更の最も直接的な原因は、ユーザーの入力と操作です。たとえば、ユーザーが選択ボックスコンポーネントでオプションを選択すると、 stateや子childrenも変更されます。

図の右側の状況は、コンポーネント開発者とコンポーネントの関係です。その 1 つは、開発者がコンポーネントのMarkup Codeを使用してコンポーネントに影響を与えることです。実際、開発者はコンポーネントAttributeを使用して、コンポーネントの一部の機能や特性を変更します。

属性は宣言型言語であり、標記型代碼Markup Codeでもあります。また、マークアップコードは必ずしも HTML のような XML のような言語ではありません。マークアップ言語の大規模なエコシステムには、インターフェースの構造を記述するために使用できる言語が実際に多数あります。しかし、最も主流なものは XML システムに基づいています。 Web 分野で最も一般的なのは XML です。 JSX は、プログラミング言語に埋め込まれた XML 構造として理解することもできます。

開発者は、 Attributeを使用するだけでなく、 Property を使用してコンポーネントに影響を与えることもできます。このコンポーネント自体にはPropertyがあります。開発者がコンポーネントのプロパティを変更すると、コンポーネントが変更されます。これは、オブジェクト内の屬性Propertyと同じ概念です。

属性とプロパティは同じですか?そうなる場合もあれば、そうでない場合もあります。すべてはコンポーネントシステムの設計者次第です。コンポーネントの実装者または設計者は、 attributeとpropertyを統合できます。 state 、 config 、 attribute 、 propertyを統合することもできます。

次に、複雑なプロセスを記述するために使用される方法methodがありますが、JavaScript のPropertyにはgetやsetなどのメソッドが許可されているため、最終的にはmethodとpropertyの機能は似ています。

したがって、ここでは、コンポーネントを使用する開発者が、これらのコンポーネントの要素であるmethodとpropertyを使用するという概念を決定できます。ただし、コンポーネント開発者がコンポーネントを使用するプログラマーにメッセージを渡す必要がある場合は、事件eventが必要になります。コンポーネントが特定の動作またはイベントにより変更をトリガーすると、コンポーネントはユーザーにeventメッセージを送信します。したがって、ここでのeventの方向は逆で、コンポーネントから外部に送信されます。

この図を通して、コンポーネントの各要素の機能と情報の流れの方向を明確に理解することができます。

属性

コンポーネントのすべての要素の中で最も複雑なのは、 AttributeとPropertyです。

英語の単語「 Attributeに対する私たちの理解は、記述性を重視しています。たとえば、ある人物が髪の毛が豊かで、ハンサムで、肌が白いと表現する場合、これらはすべてAttribute 、つまり何かの特性や特徴の説明です。

Propertyはむしろ従属的な関係です。たとえば、開発中に、別のオブジェクトであるPropertyを持つオブジェクトが見つかることがよくあります。それらの間には従属関係があり、子オブジェクトは親オブジェクトに従属している可能性が高いです。しかし、ここでは特別なケースもあります。弱参照の場合、1 つのオブジェクトが別のオブジェクトを参照しますが、これはまったく異なる概念です。

上記は英語におけるこれら 2 つの単語の違いについての説明ですが、実際の適用シナリオでも異なります。

Propertyは従属関係であるため、オブジェクト指向プログラミングでよく使用されます。 Attribute元々 XML で使用されていました。時には同じで、時には違うこともあります。

属性とプロパティ

ここでは、属性とプロパティの違いを確認するためにいくつかの例を使用します。 HTML では同等ではないシナリオを見てみましょう。

属性：

<my-component 属性="v" />
<スクリプト>
 myComponent.getAttribute('a')
 myComponent.setAttribute('a', 値)
</スクリプト>

HTMLの属性はHTML属性を通じて設定できる
JavaScript経由でも設定できます

財産：

myComponent.a = '値';

ここでは特定の要素a = 'value'を定義します
これは属性ではなく、プロパティです。

多くの学生は、これらは単に 2 つの異なる書き方であると考えていますが、実際には動作が異なります。

クラス属性

<div class="class1 class2"></div>
<スクリプト>
 var div = document.getElementByTagName('div');
 div.className // 出力はclass1 class2	
</スクリプト>

JavaScript の初期には、Class はキーワードであったため、キーワードとしての初期の class は属性名として使用できませんでした。しかし、現在ではこれは変更されており、キーワードも属性名として使用できるようになりました。

このキーワードをこのように使用できるようにするために、HTML で妥協的な設計が行われました。 HTML では属性は依然としてclassと呼ばれますが、DOM オブジェクトではプロパティはclassNameになります。しかし、二人は依然として相互に反省し合う関係にあり、この不思議な関係はしばしば人々を落とし穴に導くことになる。

たとえば、React では、className を記述すると、Class が自動的に設定されます。

スタイルプロパティ

現在、JavaScript 言語では、クラスと className の間に矛盾はありません。 div.classを使用できます。ただし、HTML は依然として name クラスをサポートしていません。これは、歴史的な問題が原因です。

属性は文字列である場合もありますが、プロパティは文字列をセマンティック文字列に変換するオブジェクトです。最も典型的なのはStyleです。

<div class="class1 class2" style="color:blue"></div>
<スクリプト>
 var div = document.getElementByTagName('div');
 div.style // これはオブジェクトです</script>

HTML の Style 属性は文字列であり、getAttribute と setAttribute を使用してこの属性を取得および設定できます。しかし、Style プロパティを使用すると、キーと値の構造が得られます。

Href属性

HTML では、 href属性とプロパティの意味は非常に似ています。しかし、そのプロパティは解決された URL です。

たとえば、href の値は「//m.taobao.com」です。このとき、以前の http または https プロトコルは現在のページに基づいているため、ここでの href は現在のページのプロトコルに対応するように再度コンパイルする必要があります。

http から https への変換を行ったことがある人なら、Web サイトで https プロトコルを使用するようにする場合、ハードコードされた http または https URL をすべて//使用するように変更する必要があることを知っているはずです。

したがって、 href に書き込んだものはすべて出力されます。それが属性です。解決されればそれは私たちの財産になります。

<a href="//m.taobao.com" rel="外部nofollow" ></a>
<スクリプト>
 var a = document.getElementByTagName('a');
 // 結果は「http://m.taobao.com」です。このURLは解決の結果です。 // これはプロパティです
 .href;
 // これは「//m.taobao.com」で、HTMLコードとまったく同じです。// これは属性です
 属性を取得します。
</スクリプト>

上記のコードでは、プロパティと属性の両方に同時にアクセスできることもわかります。意味的には非常に近いですが、同じものではありません。

しかし、どちらか一方を変更すると、もう一方も変更されます。これは私たちが注意を払う必要がある現象です。

入力と値

これは最も魔法的なペアであり、価値も特別なピットです。

多くの人は、プロパティと属性の値は完全に同等であると考えています。実はそうではありません。この属性の入力値は、値のデフォルト値と同等です。ユーザーが入力に値を入力するか、開発者が JavaScript を使用して入力に値を割り当てるかに関係なく、入力の属性は変更されません。

入力を表示するときは、プロパティが最初に表示されるため、属性の値はデフォルト値と同等になります。これは非常に有名な落とし穴です。初期の JQuery を使用したことがある人なら、prop と attr は同じものだと考えるでしょうが、ここで落とし穴に陥ってしまいます。

その後、JQuery ライブラリに val と呼ばれるメソッドが追加され、属性やプロパティの値について考える必要がなくなり、提供される val を直接使用して値を取得できるようになりました。

一方で、HTML のプロパティと属性に関する知識を深めます。その一方で、トップクラスのコンピューター専門家によって設計されたラベル付けシステムであっても、2 つの類似した属性が同等ではないという問題が発生する可能性があることに気づかされます。では、タグ付けシステムを設計するように求められた場合、プロパティと属性を同等にするでしょうか、それともそうでないでしょうか?コンポーネント化された知識全体を学習した後、この質問に一緒に答えてみましょう。

コンポーネントの状態を設計する方法

ここでは、コンポーネント設計におけるproperty 、 attribute 、 state 、 configの違いを分析します。

ここで、Winer 先生は 4 つのシナリオに分けた表を作成しました。

マークアップセット—— タグを使用して設定する
JavaScript設定- JavaScriptコードを使用して設定する
JavaScriptの変更- JavaScriptコードを使用して変更する
ユーザー入力の変更- エンドユーザーの入力によって変更

マークアップセット	JavaScript セット	JavaScriptの変更	ユーザー入力の変更
❌	✅	✅	❓	財産
✅	✅	✅	❓	属性
❌	❌	❌	✅	州
❌	✅	❌	❌	設定

それでは一つずつ説明していきましょう。

財産

❌ マークアップのような静的な宣言型言語では設定できない
✅ ただし、JavaScript で設定および変更できます
❓ ほとんどの場合、プロパティはユーザー入力によって変更されるべきではありませんが、場合によっては、プロパティがビジネスロジックから取得され、ユーザー入力によって変更されることがあります。

属性

❓ プロパティと同様に、ユーザー入力によって必ずしも変更されるわけではありません
✅ マークアップと JavaScript で設定でき、JavaScript で変更することもできます

❌ 状態はコンポーネントの外部からではなく、コンポーネントの内部から変更されます。コンポーネントの状態を外部から変更するようにコンポーネントを設計する場合、コンポーネント内の状態は制御不能になります。コンポーネントの状態がコンポーネント外部でいつ変更されるかわからないため、状態の一貫性は保証されません。
✅ しかし、コンポーネントの設計者および実践者として、ユーザー入力によってコンポーネントの状態を変更できるようにする必要があります。たとえば、ユーザーがタブをクリックすると、タブがアクティブになります。この種のインタラクションは通常、状態によって制御されます。

設定

✅ Config はコンポーネント内で一度だけ実行されるもので、コンポーネントが構築されたときにのみトリガーされます。だからそれは不変です。また、不変性のため、通常は構成をグローバルレベルに残します。通常、各ページには設定があり、それをページ内で使用します。

コンポーネントのライフサイクル

ライフサイクルに関して言えば、最も簡単に思い浮かぶのはcreatedとdestroyの 2 つです。世の中のあらゆる生命には出生と死亡という二つのライフサイクルが存在します。

では、これら 2 つの始まりと終わりの間のライフサイクルとは何でしょうか?コンポーネントの構築と破棄の間に何が起こるかを考える必要があります。

コンポーネントに関して非常に重要なことの 1 つは、作成後に表示されるかどうかです。これには、ライフサイクル内のmount 、つまりコンポーネントが「画面上のツリー」にマウントされているかどうかが関係します。このライフサイクルは、React と Vue で確認できます。コンポーネントがマウントされた後、対応する初期化操作を実行するために、このライフサイクルがよく使用されます。

マウントがある場合はアンマウントも必要となるため、コンポーネント内のmountおよびunmountライフサイクルのセットになります。マウントとアンマウントのライフサイクル全体は繰り返し発生する可能性があります。マウントしてアンマウントし、再度マウントするというライフサイクルを何度も繰り返すことができます。

したがって、 unmount後は、 createdコンポーネントのライフサイクルの状態に戻ることができます。

では、コンポーネントの状態はいつ変化するのでしょうか?ここでは 2 つの状況があります。

プログラマーはコードを使用してこのコンポーネントの状態を変更または設定します
ユーザー入力はコンポーネントの状態に影響します

たとえば、ユーザーがボタンまたはタブをクリックすると、このコンポーネントの状態の変更がトリガーされます。同時に、コンポーネントのライフサイクルも生成され、このライフサイクルは Render レンダリングまたは Update 更新です。

これらすべてのライフサイクルを合計すると、コンポーネントの完全なライフサイクルになります。私たちが目にする、いわゆるwillMountとdidMount 、このライフサイクル内のより詳細な場所にすぎません。以下にライフサイクル全体の写真を添付します。

子供たち

最後に、子供の概念についてお話ししましょう。子はコンポーネントツリーを構築するための最も重要なコンポーネント機能であり、実際に使用される子には次の 2 つの種類があります。

コンテンツタイプ子- 複数の子がありますが、最終的には複数の子を表示できます。このタイプの子の場合、コンポーネントツリーは非常に単純です。
テンプレートタイプ子- このとき、子全体がテンプレートとして機能します。たとえば、 listを設計しますが、最終結果は Children コードに記述したものと一致しない可能性があります。リストは複数のリストデータに使用されるため、表されるリストの数はコンポーネントに渡すデータに関連します。実際の子が 100 個ある場合、リストテンプレートは 100 回コピーされます。

コンポーネントツリーの子要素を設計するときは、これら 2 つの異なるシナリオを考慮する必要があります。たとえば、React ではテンプレート型の子はありませんが、その子は関数を渡すことができ、この関数は子を返すことができます。このとき、テンプレート childrenとして機能します。したがって、Vue で無限スクロールリストを作成する場合、Vue のテンプレートの子には特定の要件があります。

結論

ここでは、コンポーネント全体の概念と知識を学びました。次の記事では、コンポーネントシステムを設計および構築し、さまざまな実用的な知識について学習します。また、コンポーネントの実装について誰もが理解できるように、いくつかの一般的なコンポーネントと一般的な機能も使用します。

ここでは、私たちは互いに監督し、励まし合い、一緒に一生懸命に努力して、人生における学習の道を歩み、学習によって人生を変えていきます。

学びの道は退屈で孤独ですが、これによってより多くの仲間と励ましが得られることを願っています。一緒に応援しましょう！ (๑•̀ㅂ•́)و

フロントエンドコンポーネント化の基礎知識に関するこの記事はこれで終了です。より関連性の高いフロントエンドコンポーネント化、フロントエンドの基礎知識、フロントエンド知識のコンテンツについては、123WORDPRESS.COM の過去の記事を検索するか、以下の関連記事を引き続き閲覧してください。皆様、今後とも 123WORDPRESS.COM をよろしくお願いいたします。

以下もご興味があるかもしれません: