Ionic 3 Composant vs Page
Pouvez-vous me dire quelle est la différence entre Component et Page générateur dans le Ionic 3 app? Il semble que je puisse aussi utiliser des crochets de cycle de vie de page tels que ionViewWillLeave à l'intérieur du composant. Quand dois-je utiliser angular crochets de cycle de vie alors? Si c'est la même chose, alors pourquoi Nous espérons que vous donnerez un retour pour cela.
Générateur de composants:
ionic generate component SubscribeTopicComponent
Générateur de page:
ionic generate page LoginPage
Basé sur la conversation à partir des commentaires:
Il peut en être de même du point de vue Angular, mais Pages et Composants ont une signification différente en ionique. En termes angulaires, les deux ne sont que des composants , mais dans le contexte de Ionic, une page est un composant qui agira comme une vue entière (elle peut avoir des composants imbriqués); nous voyons les pages Ionic comme un concept autonome . Un composant fera simplement partie d'un composant plus important la plupart du temps dans les applications Angular, alors je suppose que c'est la plus grande différence avec Pages.
À propos de l'utilisation des points d'ancrage du cycle de vie d'Angular, j'aime les utiliser pour les composants imbriqués, mais je préfère les points d'ancrage du cycle de vie Ionic lorsque vous travaillez sur des pages. Principalement parce que des choses comme ionViewWillEnter n'ont pas beaucoup de sens dans le contexte d'un composant simple, où ngOnInit en a. Cela étant dit, j'ai également utilisé des Angular hooks de cycle de vie sur Pages, comme le ngOnDestroy (je l'ai utilisé pour supprimer tous les abonnements d'une page lorsque cette page est sur le point d'être détruite), mais comme vous l'avez dit, ionViewWillUnload semble être la bonne façon de procéder si nous voulons utiliser les hooks du cycle de vie d'Ionic.
J'imagine que la plupart des crochets Ionic du cycle de vie sont davantage liés à la manière dont l'utilisateur interagit avec la page dans son ensemble (entrera dans une page, sortira d'une page, pourra entrer dans une page, partira d'une page ...) et Angular Les hooks de cycle de vie sont davantage liés aux différentes étapes de la vie d’un composant (les entrées ont été initialisées, le détecteur de modification a vérifié s’il y avait des modifications de ce composant, ...), qui Comme vous pouvez le constater, l’interaction entre utilisateurs n’est peut-être pas directement liée et il s’agit généralement de choses que l’utilisateur ne connaît pas.
Je suis presque sûr qu'il n'y a pas de règle sur la meilleure approche, mais le plus important est la cohérence. Je pense qu'il est judicieux d'utiliser des crochets Ionic du cycle de vie dans les composants Pages, et d'utiliser des crochets Angular au sein de composants imbriqués . , mais vous pouvez utiliser une approche différente, à condition de le faire systématiquement dans l’application entière.
Il existe deux générateurs distincts car un décorateur supplémentaire a été ajouté à ionic: @IonicPage
Ce décorateur offre quelques avantages par rapport à un composant simple.
Routage - vous pouvez indiquer quelle est l'URL de la page, comment s'y rendre et quel est son historique par défaut. Avec cela, vous pouvez accéder directement à n'importe quelle page sans passer par le chemin de navigation. Le routage vers cette page peut également être effectué avec une chaîne plutôt qu'avec le composant réel.
Chargement paresseux - le module d'une page comportant ce décorateur sera chargé par défaut lorsque vous accédez à l'URL de la page.
Aucune confiance dans les modules d'application - il s'agit davantage d'un favori personnel, mais lorsque vous créez des modules qui sont des pages, vous ne devez pas les ajouter à votre ngModule d'origine, ce qui est fait automatiquement lors de la compilation.
Pour plus de documentation: https://ionicframework.com/docs/api/navigation/IonicPage/