C'est une question de comportement et de sémantique. Avec un
-
Subject - un abonné ne recevra que les valeurs publiées qui ont été émises après l'abonnement. Demandez-vous si c'est ce que vous voulez. L'abonné a-t-il besoin de savoir quoi que ce soit sur les valeurs précédentes ? Si ce n'est pas le cas, vous pouvez l'utiliser, sinon choisissez l'une des autres solutions. Par exemple, avec la communication entre composants. Disons que vous avez un composant qui publie des événements pour d'autres composants lors d'un clic sur un bouton. Vous pouvez utiliser un service avec un sujet pour communiquer.
-
BehaviorSubject - la dernière valeur est mise en cache. Un abonné obtiendra la dernière valeur lors de son inscription initiale. La sémantique de ce sujet est de représenter une valeur qui change dans le temps. Par exemple, un utilisateur connecté. L'utilisateur initial peut être un utilisateur anonyme. Mais dès qu'un utilisateur se connecte, la nouvelle valeur est l'état d'utilisateur authentifié.
El BehaviorSubject est initialisé avec une valeur initiale. Ceci est parfois important pour les préférences de codage. Disons par exemple que vous l'initialisez avec une valeur null . Ensuite, dans votre abonnement, vous devez effectuer un contrôle de nullité. C'est peut-être bon, ou peut-être ennuyeux.
-
ReplaySubject - il peut mettre en cache jusqu'à un nombre spécifié d'émissions. Tous les abonnés obtiendront toutes les valeurs mises en cache lors de leur inscription. Quand auriez-vous besoin de ce comportement ? Honnêtement, je n'ai pas eu besoin d'un tel comportement, sauf dans le cas suivant :
Si vous initialisez un ReplaySubject avec une taille de tampon de 1 alors, en fait, c'est se comporte comme suit : comme un BehaviorSubject . La dernière valeur est toujours mise en cache, de sorte qu'elle agit comme une valeur qui change au fil du temps. Avec cela, il n'est pas nécessaire d'avoir un null contrôle comme dans le cas de la BehaviorSubject initialisé avec un null car aucune valeur n'est jamais émise vers l'abonné avant la première publication.
Il s'agit donc de déterminer le comportement que vous attendez, pour savoir lequel utiliser. La plupart du temps, vous voudrez probablement utiliser une fonction BehaviorSubject car ce que vous voulez vraiment représenter, c'est la sémantique de la "valeur dans le temps". Mais personnellement, je ne vois rien de mal à ce que la substitution de ReplaySubject initialisé avec 1 .
Ce que vous voulez éviter utilise la vanille Subject alors que ce dont vous avez réellement besoin, c'est d'un comportement de mise en cache. Prenons l'exemple d'une garde de routage ou d'une résolution. Vous récupérez des données dans cette garde et les placez dans un service Subject . Ensuite, dans le composant acheminé, vous vous abonnez au sujet du service pour essayer d'obtenir la valeur qui a été émise dans la garde. OOPs. Où est la valeur ? Elle a déjà été émise, DUH. Utilisez un sujet "cache" !
Voir aussi :
