javascript - Sujeto vs Comportamiento Sujeto vs Repetir Sujeto en Angular

ng-if

Question

He estado buscando entender esos 3:

Sujeto , sujeto de comportamiento y sujeto de repetición . Me gustaría usarlos y saber cuándo y por qué, cuáles son los beneficios de usarlos y, aunque he leído la documentación, he visto tutoriales y buscado en Google, no he podido entenderlo.

Entonces, ¿cuál es su propósito? Un caso del mundo real sería muy apreciado, ya que no tiene que codificar.

Preferiría una explicación limpia no solo "a + b => c a la que está suscrito ..."

Gracias

Answer 1

Del libro de Randall Koutnik "Construya sitios web reactivos con RxJS":

Un sujeto es un objeto que es un observable turboalimentado. En esencia, un Sujeto actúa de manera muy similar a un observable regular, pero cada suscripción está conectada a la misma fuente. Los sujetos también son observadores y tienen métodos siguientes, de error y realizados para enviar datos a todos los suscriptores a la vez. Debido a que los sujetos son observadores, se pueden pasar directamente a una llamada de suscripción, y todos los eventos del observable original se enviarán a través de los sujetos a sus suscriptores.

Podemos usar ReplaySubject para rastrear el historial. Un ReplaySubject registra los últimos n eventos y los devuelve a cada nuevo suscriptor. Por ejemplo en la aplicación de chat. Podemos usarlo para rastrear el registro del historial de chat anterior.

Un BehaviorSubject es una versión simplificada del ReplaySubject . El ReplaySubject almacenó un número arbitrario de eventos, el BehaviorSubject solo registra el valor del último evento. Cada vez que un BehaviorSubject registra una nueva suscripción, emite el último valor para el suscriptor, así como cualquier valor nuevo que se pase. El BehaviorSubject es útil cuando se trata de unidades de estado individuales, como las opciones de configuración.

Answer 2

Realmente se reduce a comportamiento y semántica. Con un

• Subject : un suscriptor solo obtendrá los valores publicados que se emitieron después de la suscripción. Pregúntate, ¿eso es lo que quieres? ¿El suscriptor necesita saber algo sobre los valores anteriores? De lo contrario, puede usar esto, de lo contrario, elija uno de los otros. Por ejemplo, con comunicación de componente a componente. Supongamos que tiene un componente que publica eventos para otros componentes con solo hacer clic en un botón. Puede utilizar un servicio con un tema para comunicarse.

• BehaviorSubject : el último valor se almacena en caché. Un suscriptor obtendrá el último valor en la suscripción inicial. La semántica de este tema es representar un valor que cambia con el tiempo. Por ejemplo, un usuario conectado. El usuario inicial puede ser un usuario anónimo. Pero una vez que un usuario inicia sesión, el nuevo valor es el estado de usuario autenticado.

  BehaviorSubject se inicializa con un valor inicial. Esto a veces es importante para codificar las preferencias. Digamos, por ejemplo, que lo inicializa con un null . Luego, en su suscripción, debe hacer una verificación nula. Tal vez está bien, o tal vez molesto.

• ReplaySubject : puede almacenar en caché hasta un número específico de emisiones. Cualquier suscriptor obtendrá todos los valores almacenados en caché al momento de la suscripción. ¿Cuándo necesitarías este comportamiento? Honestamente, no he tenido necesidad de tal comportamiento, excepto por el siguiente caso:

  Si inicializa un ReplaySubject con un tamaño de búfer de 1 , en realidad se comporta como un BehaviorSubject . El último valor siempre se almacena en caché, por lo que actúa como un valor que cambia con el tiempo. Con esto, no hay necesidad de una verificación null como en el caso del BehaviorSubject inicializado con un null , porque nunca se emite ningún valor al suscriptor hasta la primera publicación.

Por lo tanto, realmente se reduce el comportamiento que espera, en cuanto a cuál usar. La mayoría de las veces probablemente querrá usar un BehaviorSubject porque lo que realmente quiere representar es ese semántico de "valor en el tiempo". Pero personalmente no veo nada malo con la sustitución de ReplaySubject inicializada con 1 .

Lo que desea evitar es usar el Subject vainilla cuando lo que realmente necesita es un comportamiento de almacenamiento en caché. Tomemos, por ejemplo, que está escribiendo una protección de ruta o una resolución. Obtiene algunos datos en esa protección y los configura en un Subject servicio. Luego, en el componente enrutado, se suscribe al servicio sujeto para tratar de obtener el valor que se emitió en la protección. OOPs. ¿Dónde está el valor? Ya fue emitido, DUH. Utilice un tema de "almacenamiento en caché"!

Ver también:

• ¿Cuáles son los sujetos de RxJS y las ventajas de usarlos?

Answer 3

Un resumen útil de los diferentes tipos observables, nombres no intuitivos que sé jajaja .

• Subject : un suscriptor solo obtendrá valores publicados al respecto una vez realizada la suscripción.
• BehaviorSubject : los nuevos suscriptores obtienen el último valor publicado O el valor inicial inmediatamente después de la suscripción.
• ReplaySubject : los nuevos suscriptores obtienen los últimos 1-n valores publicados inmediatamente después de la suscripción (solo si se emitieron previamente).