Ionic 3 コンポーネントとページの比較 質問する

コメントからの会話に基づいて:

Angular の観点からは同じかもしれませんが、Ionic ではページとコンポーネントの意味が異なります。Angularの観点から言えば、どちらも単なるコンポーネントです、 しかしIonicの文脈では、ページは次のような役割を果たすコンポーネントです。全体図（ネストされたコンポーネントを持つ場合があります）Ionicページはスタンドアロンコンセプトほとんどの場合、Angular アプリではコンポーネントはより大きなコンポーネントの一部に過ぎないので、これが Pages との最大の違いだと思います。

Angular のライフサイクル フックを使用する場合については、ネストされたコンポーネントで作業するときには使用したいのですが、ページで作業するときは Ionic のライフサイクル フックの方が好きです。主な理由は、 のようなことはionViewWillEnter単純なコンポーネントのコンテキストではあまり意味をなさないからですngOnInit。そうは言っても、私はページでも のような Angular ライフサイクル フックをいくつか使用しましたngOnDestroy(ページが破棄されるときにページからすべてのサブスクリプションを削除するために使用しました)。しかし、おっしゃるとおり、ionViewWillUnloadIonic のライフサイクル フックを使用する場合は、 が正しい方法のようです。

たぶんほとんどIonicライフサイクルフックは、ユーザーがページ全体とやりとりする方法に関係しています。(ページに入る、ページから出る、ページに入ることができる、ページから出ることができる...)Angularライフサイクルフックは、単一コンポーネントのライフサイクルのさまざまな段階に関連しています。(入力が初期化され、変更検出器がこのコンポーネントに変更があったかどうかをチェックしました、...) ご覧のとおり、これらはユーザー操作とはまったく直接関係がなく、通常はユーザーが気付かないものです。

どちらのアプローチが優れているかというルールはないと思いますが、最も重要なのは一貫性です。ページであるコンポーネントではIonicライフサイクルフックを使用し、ネストされたコンポーネント内ではAngularライフサイクルフックを使用するのが理にかなっていると思います。ただし、アプリ全体で一貫して行う限り、別のアプローチを使用することもできます。