-1
votes

Est-il possible de recréer le comportement des tuyaux NGIF et ASYNC dans le fichier composant?

J'ai deux composants, un composant de formulaire et une page de remerciement. (Les listes de code complet sont ici: Quel est le moyen approprié de partager des données entre deux composants à l'aide de RXJS ReplaySubject? )

Je manipule des observables Utilisation de NGIF et du tuyau ASYNC comme suit: P>

<div *ngIf='(message$ | async) as msg'>
...
</div>


2 commentaires

Veuillez marquer comme accepté si cela répondit à votre question


@getName Merci beaucoup pour votre réponse, mais je n'ai pas répondu à ma question. Merci quand même


3 Réponses :


0
votes

Je ne suis pas vraiment sûr de savoir comment vous pouvez travailler avec une fois observable avec deux abonnements.

Si vous souhaitez naviguer à l'utilisateur à l'aide de routeur.navigate (...) code> et vous vous êtes déjà abonné au observable code> dans votre classe dossier, pourquoi ne pas utiliser la même variable de votre modèle et supprimer le tuyau async code> de votre modèle. P> C'est comme ça que cela ressemblerait au code: p>

dans votre classe de composants: p> xxx pré>

et dans votre modèle: P>

<div *ngIf='msg'>
  ...
</div>


3 commentaires

Merci pour votre réponse. Je suis capable de travailler avec deux abonnés parce que j'utilise un sujet. Si je rafraîchis la page de remerciement, je souhaite rediriger l'utilisateur sur la page de formulaire. (Pas de valeur = aucun formulaire n'a été soumis). C'est pourquoi j'ai demandé comment NGIF ainsi que les travaux de tuyaux ASYNC, je dois reproduire ce comportement. Dans mon cas, l'observable n'émettra jamais de valeur si vous actualisez la page de remerciement. Je ne veux tout simplement pas que l'utilisateur voie la page de remerciement avant de remplir le formulaire.


Pouvez-vous émettre une chaîne vide pour rafraîchir? Si vous faites cela, le si est toujours satisfait et que vous liez les msg dans * ngif Le message de remerciement gagné " t apparaître.


Merci beaucoup pour votre aide, mais non, ça ne marche pas. Afin de traiter l'élément supplémentaire, je devrais ajouter une logique supplémentaire, ce qui ne semble pas être le résultat que je recherche. Merci quand même



0
votes

J'utilisais un replaySubject au lieu d'un comportement. Ce n'était pas juste, à la fin, j'ai omis la partie la plus importante. Un comportement est utile de vérifier comment une valeur évolue au fil du temps.

Je suis passée à un comportement dans un comportement, car il émettra toujours la dernière valeur lors de l'abonnement, il n'est pas nécessaire d'ajouter une logique supplémentaire ni d'émettre des valeurs supplémentaires, ou de vérifier si l'observable est "vide".


1 commentaires

En réalité, ce n'est pas complètement vrai, car le comportement de Comportours a une valeur initiale que vous spécifiez lors de la création, et il stocke toujours le dernier émis, pour un replaySubject, il a la possibilité de disposer de plusieurs valeurs à stocker, vous spécifiez que lorsque vous créez. ça, mais il n'a pas de valeur initiale ^^ C'est la vraie différence réellement



1
votes

Je pense que vous ne devez pas l'utiliser dans le fichier TS, en tant que tuyau ASYNC, effectuez l'abonnement et la désinscription automatiquement sans fuites. Pour votre cas, l'équipe angulaire suggère simplement d'utiliser des émetteurs et des intrants pour partager des données entre composants (et principalement à l'aide de composants intelligents, les seuls composants peuvent procéder et partager des données à d'autres personnes, il existe également la stratégie de données de partage de services que je ne suis pas un beaucoup d'amusement). Exemple de partage des données entre 2 composants à l'aide d'émetteurs et d'intrants en passant par le parent:
- Componenta: xxx

et xxx

- parent: xxx

et < / p> xxx

- composantb: xxx

et xxx

vous pouvez Partage de données de manière dans l'autre sens en utilisant la même stratégie, cette stratégie est une meilleure pratique recommandée par des experts angulaires, j'ai répondu par cet exemple parce que je crois que les problèmes que vous obtenez de la mise en œuvre de votre fonctionnalité proviennent du partage des données et de ne pas manipuler des observables et de ne pas manipuler Rappelez-vous, c'est une très mauvaise pratique de nier 2 abonnages ou d'utiliser des abonnements sur le fichier TS lorsque vous pouvez éviter cela en utilisant le tuyau ASYNC sur le modèle.


0 commentaires