angular 4におけるmodalの使用経験の共有
7120 ワード
本文は実际のプロジェクトの中で现れたいくつかの问题に対する経験の総括ですが、私はまだ先头の白ですが、このような记录の方式を通じて経験を蓄积することができることを望んで、文章を见る各位に少し助けて第1回angular 4でプロジェクトをすることができることを望んで、多くの愚かな方法あるいは论理の上で厳格ではありません
多くのビジネスシーンではmodalボックスがポップアップされ、詳細を記入したり、情報を間違えたりするなどのビジネスニーズがあります.angular 4のmodalがどのようにデータのインタラクションを行うか、ポップアップと消失の制御について心得を共有します.
1.簡単な親子関係
modalは常に特定のページによってトリガーされるため、modalのcomponentとトリガーされるcomponentは親子関係を有する.親子関係のデータ伝達は比較的簡単で、よく使われるのはInput/Outputでデータを伝達したり、serviceでデータの中継をしたりして、最も簡単な親-子コンポーネントのデータ伝達に対して、普通のInput/Outputはすでに要求を満たすことができます(コードは書かないのは複雑すぎて、export classの中のコードだけを書きましたハ)
ModalComponent.ts
ParentComponent.html
ParentComponent.ts
これは最も簡単なビジネスニーズですが、筆者が複雑なmodalを実現する基礎原理でもあります.
2.複数modalの処理
最も簡単な親子関係を経験した後、一人っ子家庭から二人っ子政策の開放に需要が高まった.同じ親コンポーネントの下で、ビジネスのニーズに応じて、2つ、3つ、さらに多くのmodalをポップアップする可能性があります.筆者も、1つのcomponentで入力価値に応じて、ターゲット表示を行うことを考えたことがあります.
しかし、この個人はこの書き方が優雅ではないと考えています.10個8個のmodalが必要な場合、コードのメンテナンス性が低下するため(少なくとも煩わしいように見えます)、modalごとにcomponentを作るべきではないかと考えています.htmlコードの清潔さにも役立ち、tsのコードをより美しく、メンテナンスしやすいようにしています.
ParentComponent.html
これで少し良くなったように見えますが、醜いのはParentのhtmlファイルの末尾にmodalのラベルコマンドが山積みされるので、筆者は祖父-父-子構造の処理方法を考えました.祖父コンポーネントはmodal表示のトリガを担当し、トリガしたmodalを親コンポーネントに転送し、親コンポーネントから子modalの選択を行います.これにより,多くのmodalが同じページに存在しても,親コンポーネントが中継者としてトリガーされ,本質的な原理は同じであり,メディアを1層追加しただけであるが,分業をより明確にすることができる.GrandParentComponent.html
ParentComponent.html
このようなテクニックは、各modalを分割し、modalをフィルタする機能をinput属性を介して祖父コンポーネントから親コンポーネントに渡し、親コンポーネントが単純な変数伝達者になった.このステップでは、親コンポーネントの追加により、変数の伝達プロセスが親-子-父から祖父-父-子-父-祖父になったことを意味し、このようなデータ量を達成するためにEventEmitterの山ほど多くのデータを送信する可能性があるため、このような問題もあります.今から見れば,このやり方には確かに冗長性があるが,この構造の武力行使の場はこのような簡単なコンポーネント関係ではない.
3.再帰コンポーネントのmodal処理
Angular 4では、ngForが空のデータを循環して現れる可能性のあるデッドサイクルバグが修復され、これは、再帰コンポーネントに対して良いメッセージコンポーネントである再帰は、コンポーネント内で自身を再呼び出し、このような需要が発生する可能性のあるシーンを指し、最も典型的にはツリーデータ構造のループ表示である.
ツリー構造の展開可能なインデント付きドロップダウンリストを表示する必要があると仮定すると、各ノードのuiは本質的に同じであるため、同じcomponentを使用して再帰的に呼び出すのが便利である.このとき、各ノードがクリックでき、modalがポップアップされ、ノードの情報を修正するために必要が追加された.この時問題が来て、modalのはどこに書くべきで、modalの中でそのノードのデータはどこから来ます.筆者の最初の考えは、modalを再帰的なcomponentに直接書けばいいのではないかと思ったが、すぐに問題を発見した.ParentComponent.html
ChildComponent.html
これは非常に典型的なangular 4のツリー構造データが再帰的に表示されるサンプルコードである.modalはノードUIをクリックすることによってトリガーされる--つまりbranch-dataの(click)イベントであるため、modalがラベルに対応する位置はノードのコンポーネントに置くことができる--これにより、ツリー構造の複雑な親子関係によるoutput/intput方法の失効をよく回避することができる.または、modalをトリガするノードを管理せずに、modalの表示をルートノードに統一して制御する
いずれにしても、別のコンポーネント間で値を伝達する方法であるサービスサービスの利点は、データの入力者出力者がどのような関係にあるかを気にすることなく、データの格納と伝達に専念できることである.サービスは典型的な単一例モードであり、一方向バインドの単一例である(しかし、いくつかの特殊なフォーマットの記憶において、サービスも双方向バインドに近い表現を示しており、具体的な原因は筆者がまだ研究している).消えた変数を表示するように制御し、EventEmitterの送信によって親コンポーネントにデータを送信することで、データの接続を実現することができます.
Modal.Service.ts
ModalComponent.ts
ParentComponent.ts
ParentComponent.html
modalComponent.html
上のコードはサービスに依存して、1つの3級の子孫関係のデータ伝達を実現してinput属性を通じて、modalを制御して消えたmodal_を表示しますname変数はすべてのmodalのコンポーネントModalComponentを制御し、childModalに挿入します.このデータ転送は表示動作を制御します.modalが消える必要がある場合、childModalでModalServiceのemit関数を送信するだけで、parentはmodal_に受け入れられます.nameの新しい値によりmodalの消失を制御
この実現方法には次のような利点がある.プロジェクトのすべてのmodalをmodalComponentに入れて制御することができ、modalComponentのinputを制御するだけでchild-modalに所望の値を得ることができ、modalの統一管理 を容易にすることができる. modalComponentには10個、20個以上のmodalが同時に置かれる可能性がありますが、ngIfで落とされたmodalは破棄されるので、本当にメモリを占有しているのはngIfがtrueのmodalだけで、メモリ漏洩の問題 を巧みに回避できます.この方法は複雑な親子関係を避けるために子孫関係が非常に有効であり、データ入力者と出力者の関係を無視し、入力出力の対象だけに集中し、一般的なoutputが複雑な階層関係に直面したときの無力 を解決した.
しかし、この方法にはいくつかの考慮すべき点があります.この実装はEventEmitterに完全に依存するため、サービスのEventEmitterを購読した後、必ず、OnDestroyでログアウトすることを覚えておいてください.Outputチャネル以外で使用されているEventEmitterは、ComponentのOnDestroyで自動的にログアウトされないので、必ず手動で購読を解除しなければなりません.そうでなければ頻繁に切り替え、コンポーネントを初期化した後、メモリ漏洩が発生するのは100%のことです. EventEmitterという使い方では、httpストリームを購読している場合、検索、フィルタリング、ソートなどの機能がある場合、バックグラウンドに頻繁に要求を送信する必要があり、毎回異なるパラメータを持つ可能性があります.この場合、購読を使用するのは良い選択であり、要求を送信する必要がある場合、サービス内のObservableを更新してemit関数を再実行するだけで、以前に購読したEventEmitterは、ストリームのsubscribeなどの方法を必要に応じて実行し、コード を多く省くことができます.
上記のようにデータを更新する方法は、OnDestroyでEventEmitterの購読をログアウトしていないと、コンポーネントを切り替えてからhttpのリクエストを送信するたびに、実際にトリガーされたhttpの数が増加していることに気づきます.これは、ログアウトしていないhttp_Emiterは実際にはemit関数の送信要件も受け取っているので、メモリにhttp_をたくさん格納している可能性があります.emitter、彼らはあなたがemit関数を実行する時同時にhttp要求を出して、結果は言うまでもなく、大量のサーバーの流量を占有します
さて、今回のまとめはこれだけですが、文章を読んでくださった皆様のお役に立てばと思います
皆さんもたくさん教えてくれることを期待しています~たくさん交流~~~
ps:コード部分は純粋な手で打ったものです.のもし何か間違いがあったら、皆さんに指摘して許してください.の
多くのビジネスシーンではmodalボックスがポップアップされ、詳細を記入したり、情報を間違えたりするなどのビジネスニーズがあります.angular 4のmodalがどのようにデータのインタラクションを行うか、ポップアップと消失の制御について心得を共有します.
1.簡単な親子関係
modalは常に特定のページによってトリガーされるため、modalのcomponentとトリガーされるcomponentは親子関係を有する.親子関係のデータ伝達は比較的簡単で、よく使われるのはInput/Outputでデータを伝達したり、serviceでデータの中継をしたりして、最も簡単な親-子コンポーネントのデータ伝達に対して、普通のInput/Outputはすでに要求を満たすことができます(コードは書かないのは複雑すぎて、export classの中のコードだけを書きましたハ)
ModalComponent.ts
export class ModalComponent implements OnInit{
// modal
@Input()
modal_info;
// modal
@Output()
hide_emitter = new EventEmitter();
constructor() {}
ngOnInit() {}
// modal
hideModal() {
// modal
this.hide_emitter.emit(emitted_info);
}
}
ParentComponent.html
ParentComponent.ts
export class ParentComponent implements OnInit {
//modal
private modal_control = '';
constructor() {}
ngOnInit() {}
// modal
showModal() {
this.modal_control = 'child_name';
}
// modal ,
getEmitter(event) {
// modal
this.modal_control = event;
}
}
これは最も簡単なビジネスニーズですが、筆者が複雑なmodalを実現する基礎原理でもあります.
2.複数modalの処理
最も簡単な親子関係を経験した後、一人っ子家庭から二人っ子政策の開放に需要が高まった.同じ親コンポーネントの下で、ビジネスのニーズに応じて、2つ、3つ、さらに多くのmodalをポップアップする可能性があります.筆者も、1つのcomponentで入力価値に応じて、ターゲット表示を行うことを考えたことがあります.
...
...
しかし、この個人はこの書き方が優雅ではないと考えています.10個8個のmodalが必要な場合、コードのメンテナンス性が低下するため(少なくとも煩わしいように見えます)、modalごとにcomponentを作るべきではないかと考えています.htmlコードの清潔さにも役立ち、tsのコードをより美しく、メンテナンスしやすいようにしています.
ParentComponent.html
これで少し良くなったように見えますが、醜いのはParentのhtmlファイルの末尾にmodalのラベルコマンドが山積みされるので、筆者は祖父-父-子構造の処理方法を考えました.祖父コンポーネントはmodal表示のトリガを担当し、トリガしたmodalを親コンポーネントに転送し、親コンポーネントから子modalの選択を行います.これにより,多くのmodalが同じページに存在しても,親コンポーネントが中継者としてトリガーされ,本質的な原理は同じであり,メディアを1層追加しただけであるが,分業をより明確にすることができる.GrandParentComponent.html
ParentComponent.html
このようなテクニックは、各modalを分割し、modalをフィルタする機能をinput属性を介して祖父コンポーネントから親コンポーネントに渡し、親コンポーネントが単純な変数伝達者になった.このステップでは、親コンポーネントの追加により、変数の伝達プロセスが親-子-父から祖父-父-子-父-祖父になったことを意味し、このようなデータ量を達成するためにEventEmitterの山ほど多くのデータを送信する可能性があるため、このような問題もあります.今から見れば,このやり方には確かに冗長性があるが,この構造の武力行使の場はこのような簡単なコンポーネント関係ではない.
3.再帰コンポーネントのmodal処理
Angular 4では、ngForが空のデータを循環して現れる可能性のあるデッドサイクルバグが修復され、これは、再帰コンポーネントに対して良いメッセージコンポーネントである再帰は、コンポーネント内で自身を再呼び出し、このような需要が発生する可能性のあるシーンを指し、最も典型的にはツリーデータ構造のループ表示である.
ツリー構造の展開可能なインデント付きドロップダウンリストを表示する必要があると仮定すると、各ノードのuiは本質的に同じであるため、同じcomponentを使用して再帰的に呼び出すのが便利である.このとき、各ノードがクリックでき、modalがポップアップされ、ノードの情報を修正するために必要が追加された.この時問題が来て、modalのはどこに書くべきで、modalの中でそのノードのデータはどこから来ます.筆者の最初の考えは、modalを再帰的なcomponentに直接書けばいいのではないかと思ったが、すぐに問題を発見した.ParentComponent.html
ChildComponent.html
......
......
これは非常に典型的なangular 4のツリー構造データが再帰的に表示されるサンプルコードである.modalはノードUIをクリックすることによってトリガーされる--つまりbranch-dataの(click)イベントであるため、modalがラベルに対応する位置はノードのコンポーネントに置くことができる--これにより、ツリー構造の複雑な親子関係によるoutput/intput方法の失効をよく回避することができる.または、modalをトリガするノードを管理せずに、modalの表示をルートノードに統一して制御する
いずれにしても、別のコンポーネント間で値を伝達する方法であるサービスサービスの利点は、データの入力者出力者がどのような関係にあるかを気にすることなく、データの格納と伝達に専念できることである.サービスは典型的な単一例モードであり、一方向バインドの単一例である(しかし、いくつかの特殊なフォーマットの記憶において、サービスも双方向バインドに近い表現を示しており、具体的な原因は筆者がまだ研究している).消えた変数を表示するように制御し、EventEmitterの送信によって親コンポーネントにデータを送信することで、データの接続を実現することができます.
Modal.Service.ts
export class ModalServcie {
private modal_emitter = new EventEmitter();
constructor() {
}
getModalEmitter() {
return this.modal_emitter;
}
emitModalName(modal_name) {
this.modal_emitter.emit(modal_name);
}
}
ModalComponent.ts
export class ModalComponent implements OnInit {
@Input()
modal_name;
constructor(private modalService: ModalService) {
}
hideModal() {
this.modalService.emitModalName('');
}
}
ParentComponent.ts
export class ParentComponent implements OnInit, OnDestroy {
private modal_emitter;
private modal_name = '';
constructor(private modalService: ModalService) {
this.modal_emitter = this.modalService.getModalEmitter()
.subscribe(data => {
this.modal_name = data;
});
}
ngOnInit() {
}
ngOnDestroy() {
this.modal_emitter.unsubscribe();
}
showModal() {
this.modal_name = 'child_name';
}
}
ParentComponent.html
modalComponent.html
上のコードはサービスに依存して、1つの3級の子孫関係のデータ伝達を実現してinput属性を通じて、modalを制御して消えたmodal_を表示しますname変数はすべてのmodalのコンポーネントModalComponentを制御し、childModalに挿入します.このデータ転送は表示動作を制御します.modalが消える必要がある場合、childModalでModalServiceのemit関数を送信するだけで、parentはmodal_に受け入れられます.nameの新しい値によりmodalの消失を制御
この実現方法には次のような利点がある.
しかし、この方法にはいくつかの考慮すべき点があります.
this.http_emitter = this.yourService.getEmitter()
.subscribe(data => {
// data http
data.subscribe(data1 => {
// data1 http
});
})
上記のようにデータを更新する方法は、OnDestroyでEventEmitterの購読をログアウトしていないと、コンポーネントを切り替えてからhttpのリクエストを送信するたびに、実際にトリガーされたhttpの数が増加していることに気づきます.これは、ログアウトしていないhttp_Emiterは実際にはemit関数の送信要件も受け取っているので、メモリにhttp_をたくさん格納している可能性があります.emitter、彼らはあなたがemit関数を実行する時同時にhttp要求を出して、結果は言うまでもなく、大量のサーバーの流量を占有します
さて、今回のまとめはこれだけですが、文章を読んでくださった皆様のお役に立てばと思います
皆さんもたくさん教えてくれることを期待しています~たくさん交流~~~
ps:コード部分は純粋な手で打ったものです.のもし何か間違いがあったら、皆さんに指摘して許してください.の