Ionic 3 Composant vs Page

Question

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 utiliser des crochets de cycle de vie de page comme ionViewWillLeave Donc, quand dois-je utiliser les crochets du cycle de vie angulaire alors ? Si c'est la même chose, pourquoi y a-t-il deux générateurs ? J'espère que vous fournirez un retour d'information à ce sujet.

Générateur de composants :

 ionic generate component SubscribeTopicComponent

Générateur de pages :

ionic generate page LoginPage

Answer 1

Basé sur la conversation des commentaires :

C'est peut-être la même chose du point de vue d'Angular, mais les pages et les composants ont une signification différente dans Ionic. En termes d'Angular, les deux sont juste des composants mais dans le contexte de Ionic, une page est un composant qui va agir comme une vue d'ensemble (il peut avoir des composants imbriqués) ; nous voyons les pages Ionic comme une concept autonome . La plupart du temps, dans les applications Angular, un composant ne sera qu'une partie d'un composant plus grand, et je pense que c'est la plus grande différence avec Pages.

À propos de l'utilisation des crochets de cycle de vie d'Angular, j'aime les utiliser lorsque je travaille dans des composants imbriqués, mais je préfère les crochets de cycle de vie de Ionic lorsque je travaille sur des pages. Principalement parce que des choses comme ionViewWillEnter n'a pas trop de sens dans le contexte d'un simple composant, où ngOnInit fait. Ceci étant dit, j'ai également utilisé certains crochets de cycle de vie d'Angular sur les pages, comme l'élément ngOnDestroy (Je l'ai utilisé pour supprimer tous les abonnements d'une page lorsque cette page va être détruite), mais comme vous l'avez dit, ionViewWillUnload semble être la bonne façon de le faire si nous voulons utiliser les crochets de cycle de vie de Ionic.

Je suppose que le plus des crochets du cycle de vie Ionic sont davantage liés à la manière dont l'utilisateur interagit avec la page dans son ensemble. (entrera sur une page, sortira d'une page, pourra entrer sur une page, pourra sortir d'une page...) et les crochets du cycle de vie d'Angular sont davantage liés aux différentes étapes de la vie d'un même composant (les entrées ont été initialisées, le détecteur de changement a vérifié s'il y avait eu des changements dans ce composant, ...), qui, comme vous pouvez le voir, peuvent ne pas être directement liés à l'interaction de l'utilisateur, et sont généralement des choses dont l'utilisateur n'est pas conscient.

Je suis presque sûr qu'il n'y a pas de règle concernant la meilleure approche, mais le plus important est la cohérence. Je pense qu'il est logique d'utiliser les crochets de cycle de vie de Ionic dans les composants qui sont des pages, et d'utiliser les crochets de cycle de vie d'Angular à l'intérieur des composants imbriqués. mais vous pouvez utiliser une approche différente, à condition de le faire de manière cohérente dans toute l'application.

Answer 2

Il y a 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 simple composant.

1. Routage - vous pouvez indiquer quelle est l'URL de la page, comment y accéder 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é à l'aide d'une chaîne de caractères plutôt qu'avec le composant lui-même.

2. Chargement paresseux - le module d'une page qui possède ce décorateur sera chargé par défaut lors de l'accès à l'url de la page.

3. Pas de dépendance au module d'application - il s'agit plutôt d'une préférence personnelle, mais lorsque vous créez des modules qui sont des pages, vous ne devez pas les ajouter à votre ngModule d'origine et cela est fait automatiquement lors de la compilation.

Pour plus de documentation : https://ionicframework.com/docs/api/navigation/IonicPage/