From what I experienced, I think it is important the make the distinction between share and shareReplay. The important distinction is what happens for late subscribers (subscribing after the emission = request has occurred). shareReplay will emit the last value when a late subscriber subscribes share will emit the same value without repeating the request for all early subscribers. Late subscribers will only receive future emissions. so shareReplay can be best used for caching data that should only be retrieved once and shared between multiple components (whenever they are created even in the future after first emission) share can be best used for preventing multiple requests when you subscribe multiple times to the observable (probably in the same view).
Excellent. I actually even got a better understanding of the `rxjs` `map` that was shown towards the beginning. I really like how he doesn't gloss over anything. Basically each line is explained in great detail.
I never use async pipe because it trigger subscribing on the html wherever you add the pipe. The data is rarely used once only in template in real world
I have one question sir if we are using this shareReplay for caching data it fine for normal cases but if any new data has been added and you want to refresh the list clicking on a button suppose then how it will refresh caz shareReplay will share the previous state right then what to do in that scenarios!? Thank you so much .
The problem that you’re solving is really caused by the use of async. At the heart of the issue is that the template is directly controlling behavior, ie it is mvvm not mvc
@@vishals50 I think a good practice when using async pipe is to first do this on a wrapping element: *ngIf="data$ | async as data" ... then safely use data variable without causing the issue in the video.
@@JBuchmannThank you for this 😃. I saw the wrapping element as you mentioned without knowing why for quite a long time. I ignore using it and ends up facing issue like this video. Now with that wrapping, my problem was solved.
Is there a way to omit shareReplay operator. For example, we edited course data in a simple form, changed it in the database and now we want to repeat API call?
Thanks for this. However how can I prevent API call to be triggered twice in case of error? E.g. when API returns Internal Server error, call is made second time again.
From what I experienced, I think it is important the make the distinction between share and shareReplay. The important distinction is what happens for late subscribers (subscribing after the emission = request has occurred).
shareReplay will emit the last value when a late subscriber subscribes
share will emit the same value without repeating the request for all early subscribers. Late subscribers will only receive future emissions.
so shareReplay can be best used for caching data that should only be retrieved once and shared between multiple components (whenever they are created even in the future after first emission)
share can be best used for preventing multiple requests when you subscribe multiple times to the observable (probably in the same view).
I was trying to understand the difference, but could not wrap my head around it until I found your comment. Thank you for this clear explanation.
Excellent. I actually even got a better understanding of the `rxjs` `map` that was shown towards the beginning. I really like how he doesn't gloss over anything. Basically each line is explained in great detail.
Best explanation on observable.. Thank you sir
This one is really great!! Thanks and Post more videos like this Sir :)
I never use async pipe because it trigger subscribing on the html wherever you add the pipe. The data is rarely used once only in template in real world
From what I learned it's best practice to always use the async pipe because it will take care of subscribing and unsubscribing automatically.
I wonder what happens if new courses are added. From my understanding page won't be updated if sharedReplay is used isn't it ?
I have one question sir if we are using this shareReplay for caching data it fine for normal cases but if any new data has been added and you want to refresh the list clicking on a button suppose then how it will refresh caz shareReplay will share the previous state right then what to do in that scenarios!? Thank you so much .
+
The problem that you’re solving is really caused by the use of async. At the heart of the issue is that the template is directly controlling behavior, ie it is mvvm not mvc
Async pipe looks charming but it's a wild operator.
@@vishals50 I think a good practice when using async pipe is to first do this on a wrapping element:
*ngIf="data$ | async as data"
... then safely use data variable without causing the issue in the video.
@@JBuchmannThank you for this 😃. I saw the wrapping element as you mentioned without knowing why for quite a long time. I ignore using it and ends up facing issue like this video. Now with that wrapping, my problem was solved.
Hello Vasco,can we use share operator in place of sharereplay operator in this example?
Is there a way to omit shareReplay operator. For example, we edited course data in a simple form, changed it in the database and now we want to repeat API call?
Thanks for this. However how can I prevent API call to be triggered twice in case of error? E.g. when API returns Internal Server error, call is made second time again.
Solution at 7:00
htp
Sweeet!