Sujeto vs comportamiento Sujeto vs repetición Sujeto en Angular

Realmente se reduce al comportamiento y la semántica. Con

• Subject - un suscriptor solo obtendrá los valores publicados que se emitieron después de la suscripción. Pregúntate, ¿es eso lo que quieres? ¿El suscriptor necesita saber algo sobre los valores anteriores? Si no, entonces 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 en un haga clic en el botón. Puede utilizar un servicio con un sujeto para comunicarse.

• BehaviorSubject - el último valor se almacena en caché. Un suscriptor recibirá el valor más reciente en la suscripción inicial. La semántica para 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.

  El BehaviorSubject se inicializa con un valor inicial. Esto es a veces es importante para la preferencia de codificación. Digamos por ejemplo que lo inicializas con un null. Luego, en su suscripción, debe hacer una comprobación nula. Tal vez bien, o tal vez molesto.

• ReplaySubject - puede almacenar en caché hasta un número especificado de emisiones. Cualquier suscriptor obtendrá todos los valores almacenados en caché al suscribirse. ¿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 búfer tamaño de 1, entonces en realidad se comporta al igual que 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.

Así que realmente se reduce al comportamiento que espera, en cuanto a cuál usar. La mayoría de las veces es probable que desee utilizar un BehaviorSubject porque lo que realmente quieres representar es ese" valor en el tiempo " semántico. Pero personalmente no veo nada malo con la sustitución de ReplaySubject inicializado con 1.

Lo que quiere evitar es usar vanilla Subject cuando lo que realmente necesita es algún comportamiento de almacenamiento en caché. Por ejemplo, está escribiendo una protección de enrutamiento o una resolución. Obtiene algunos datos en ese guardia y los establece en un servicio Subject. Luego, en el componente enrutado, se suscribe al servicio sujeto para intentar obtener el valor que se emitió en la guardia. Oops. ¿dónde está el valor? Ya estaba emitido, DUH. Utilice un sujeto" caching"!