Thanks for advic

Just by using the share() operator like you said RxJS devs recommends it to do so does not work. I mean doing `share({ connector () => new ReplaySubject(1)})` does not behave the same as `shareReplay(1)` because if the source observable behind the `share()` approach completes, the share operator connected to the ReplaySubject is going to mirror that completion when `shareReplay(1)` is not. Can you reference the concrete example of the e-Book?

Code reference: ... ```ts import { of, tap, share, shareReplay, ReplaySubject } from 'rxjs'; const source = of(1, 2, 3).pipe( tap((val) => console.log(`Source emitted ${val}`)), // share() // Replace with shareReplay(1) to see the difference // shareReplay(1), share({ connector: () => new ReplaySubject(1) }) ); source.subscribe((val) => console.log(`Subscriber 1 received ${val}`)); setTimeout(() => { source.subscribe((val) => console.log(`Subscriber 2 received ${val}`)); }, 5000); ```

Thanks for the suggestions! Just a note on implicit any - getClients etc. doesn't have an implicit any type here, the return type is inferred as Observable. Although I can get behind supplying explicit types for return types anyway, this is something I flip flop on a bit but in general I think it's good for readability.

Thanks! map/find is required in this case because the stream emissions are arrays containing all of the clients - a filter would block/allow the entire array from being emitted, in this case I want to pull just one item out of that array.

The HTTP request just completes and that is it once it has fetched the data (even though it is delivered via an observable). If you aren't using something like Firestore that streams updates by default, you might want to look into using web sockets for live updates.

Hi Josh, great video as always. I have been struggling to find the solution to the same question. When using a backend SQL database you don't really want to be setting up websockets to just get data for an API. I like the solution to prevent multiple http calls from various components you have shown. But it would be nice if there was a way to make a new http call to refresh the data for all the component subscribers. I find this type of real world use case frustrating that this is not addressed by Angular in documentation examples. For example, users get a list of data, select an item from the list of data, update that item, now we want to get/refresh the list of data so that the info is correct when clicking on the item again. Pretty simple CRUD over http. Thanks again

Subjects (BehaviorSubject and ReplaySubject) are in a different category to shareReplay which is an operator you can pipe onto an observable (which will effectively convert that observable into a ReplaySubject). A "Subject" is a special type of observable that allows you to share/multicast data to multiple subscribers (i.e. a "hot" observable). A BehaviorSubject is a Subject that always has an initial value and will always emit that value, or whatever the latest data emission was if its "next" method has been triggered, when something subscribes to it. This is often in an Angular service where you want to load some data or update some data and expose it throughout your app using an observable. Whatever subscribes to it will always get the latest value when the subscription happens, and if there have been no data emissions yet it will get that initial value that has to be supplied to it when you create it. A ReplaySubject is a Subject that will repeat X amount of the previous data emissions when something subscribes to it. If the ReplaySubject has already emitted three values (1, 2, 3) and then something subscribes to it, that subscriber will receive the old data emissions when it subscribes (1, 2, 3).

Thanks @@JoshuaMorony , Now it is starting to make sense for me . So i think behavioural subject would be good for general use cases. PS: It genuinely feels great when a youtuber make time for a detailed reply. Appreciate it !

@@tanishqmanuja Yes definitely, a super common use case is to use a BehaviorSubject to manage data in a service (think "posts", "clients", "items" etc.). Then that service would provide a method like "getPosts()" which would return the BehaviorSubject as an observable for use outside of the service. If you set the return type on the get method to be an Observable, it prevents other parts of the app from calling the BehaviorSubjects "next" method (instead things outside of the service just get access to the stream of data)

Yes, if you're sharing a hot observable with your app using a singleton service then it doesn't matter what component subscribes to it - they will all share the same stream