ShareReplay in RxJS - Hidden Pitfall You Have To Know (Advanced)

[@DecodedFrontend]

To try everything Brilliant has to offer for free for a full 30 days, visit brilliant.org/DecodedFrontend You’ll also get 20% off an annual premium subscription.

[@raviyadav-ih1dg]

Hello sir, could you please upload your advance reactive form course on udemy, i want to register as I have access of udemy. I request if it possible , please do it... thank you!

[@D4NGRB0X]

I found this quite helpful and would like to see more breakdowns of other operators in this way.

[@DecodedFrontend]

Thank you for your feedback 🙏🏻

[@ugochukwuumerie6378]

Yep, me too

[@danielnaydenov9899]

I love how you build the operators from scratch, essentially debunking the implementation behind - making it way easier to understand. Keep up the good work, love your content !

[@NguyenDoai7777]

so helpful, i use shareReplay but never knew this issue yet, great thank

[@PavloBozhok]

Thanks you for having the courage to create videos on deep topics with angular and in general frontend.

[@madeOfClay99]

Dmytro has to be the best Angular content creator on youtube, no one puts this amount of effort like him Dmytro, thank your for Angular videos! Keep up the good work

[@rtpHarry]

I hope there are more like this on the channel. I dont think i will directly use it but it is very interesting to see how the magic works. When i first tried to learn rxjs i kept getting stuck because i couldnt visualise what was going on, to be able to reason about it. It seemed so powerful that i thought there must be something more complex going on. As i learned more i slowly accepted that in a way its actually quite simple.

[@Asotado]

Amazing, i hope you make more videos like this showing the internal work of the things we use

[@s1mpler.videos]

Please continue this (recreating) approach! Totally love it!

[@alphamarouanadiallo8238]

I love this approach, thanks again as always !

[@LazarosPoumpouridis]

Great video, helps a lot on understanding how these operators work and how to use them, thanks!

[@alexjohnson-bassworship3150]

Loved this video!! Make one on every operator!!

[@kriiistofel]

Thank you for the video, it's very helpful Approach with learning things from scratch is great

[@arpitgarg6459]

Supercool video.. And kudos to your knowledge. I think I found a gold mine. Please make more insightful videos like this which debunks the internal implementations.

[@linaseiningis8349]

Great video. Actually had this problem a couple of weeks ago. Figured out that shareReplay(1) is what holds the subscription even after async pipes unsubscribe (because the component is destroyed). Always thought that putting takeUntil() at the end of the pipeline will get rid of it. But this time it was actually the other way around, I needed to put it before shareReplay(1). Just as I wanted to experiment more and find out why is that, your video came out. Thank you. The internal concepts are always good to know, so do indeed continue with these type videos. Thank you :)

[@IhorKhomiak]

The Best Angular content on KZbin! Thank you for such useful advanced topics!

[@tsGarpfin1]

Great explanation! Continue using same approach to tear down inner workings of Angular and RxJS

[@duganets]

interesting topic, thank you for your work

[@appeiroon]

Great channel, nice to see you are covering more advanced topics about Angular and related topics in an easy to understand manner

[@manoharsinghrawat1859]

Your approach is very good and makes things crystal clear

[@saeedbayat4271]

Great as always! Definitely it's a great approach to explain the matter, then implement the thing u were explaining for those who want more advanced stuff! Keep up the good work!

[@DecodedFrontend]

Thank you 🙌🏻

[@josephsackeykontor4138]

As usual, always with great content. I love this approach as it gives a clear understanding of the internals. Thanks

[@DecodedFrontend]

Great! Thanks, Joseph!

[@ExploringCodeCrafter]

I like this approach! more of it please!

[@maximermoshin393]

Thanks for sharing the knowledge. Great as always.

[@oleksandrvorovchenko8674]

Great approach. Thanks!

[@Brumry]

I would love to see some advanced rxjs video. There are many rxjs operators we use daily, however there are some which I have never used before like: iif, dematerialize, mergescan, windowTime, publish

[@volodymyrleskiv5006]

Thank you! I learned something new!

[@AlesFrankie]

I like this approach, much simpler than just theory Thanks!

[@jonatabiondiJsLover]

Your approach to go deep inside argument is awesome. Go more deep... so we learn more :) you are great

[@DecodedFrontend]

Glad to to hear that! Thank you for letting me know :)

[@n8_may]

Loved this approach!

[@DecodedFrontend]

Awesome! Thank you!

[@tarquin161234]

Many thanks for the great video. While the refCount solution is simple to understand, it has drawbacks: sometimes you may want to keep the cache even after the last unsubscription. Can you provide advise on this situation? My guess would be that we should do some kind of takeUntil immediately before shareReplay(1) (as the comment at the very beginning suggested). I think this would work as the conpletion would cause shareReplay's inner subscription to unsubscribe. If you agree, I think this would be a superior general approach to using refCount (as the cache persists even after the last unsubscription).

[@williamjog93]

Well explained!

[@ago2501]

I also like this kind of videos, it helps me to understand better the code under the hood! Thanks, Dmytro!

[@greenoxxx2827]

Thank you for creating this video! It's helped me realize how much I could improve my previous code. I'm eager to see more content from you. I recently faced a challenge with applying form controls and validators from a parent form to a custom input element. While I understand that ngModel handles control values, how can I access the validators defined in the parent form within my custom component?

[@remigiuszrajca5679]

Very nice. I like this approuch :) Do more your work! Its great :)

[@ntvkris]

Thank you Dmytro! Always find the videos material interesting.

[@deadlyecho]

Also, a socket is an example of memory leak since the internal subscription will be left alive even if the component is destroyed, right?

[@DecodedFrontend]

Yes, if the source of the nested subscription would be a socket connection (instead of polling), it would be the same problem.

[@dylanjhalltech8313]

I like this approach. Looking at source code for libraries like rxjs helps us realize it’s all just code - someone else’s code. And they code just like us 😂

[@TheSysmat]

Very good approach 🎉

[@DecodedFrontend]

Thank you! 😃

[@dariyablyazov9581]

Love it, do it more

[@atharvamusale4863]

Amazing, thanks!

[@tarquin161234]

Thanks

[@DecodedFrontend]

Wow! Huge thanks for the support 🙌

[@vasiliykrush2150]

I also like that way when we learn something by doing the same from scratch

[@AmarSingh-uw1db]

Liked the approach ❤❤❤

[@DecodedFrontend]

Awesome! Thank you :)

[@nikhilsrivastava6659]

Very helpful 👍

[@ievgensvichkar2643]

Very useful!

[@xEnergyGamingHD]

great video, love this content! :) please more advanced videos like this

[@DecodedFrontend]

🫡

[@mansur-isakov]

That was damn helpful, Dmytro! Thanks

[@rahulhnair1065]

Great content... Very helpful

[@andrelouw2677]

In your example where you have a cache that should keep running (let's say in a service). When the component disconnects, it should still keep a cached version. When the component connects again it will immediately have a value. How and where would you then kill the subscription to that first source. Lets say when the service is destroyed... in my case I have a firebase subscription that I cache in a service. All the components then use that value. How can I make sure that the firebase sub is destroyed?

[@shubhamgoel7703]

can you please make video on MicroFrontends?

[@rahultej8352]

❤❤❤

[@AlejandroMorenteCampos]

What happens with late subscriptions when the source Observable doesn't have any subscriptions left? It shouldn't make another http request in this case because the inner ReplaySubject should replay the value, right?

[@DecodedFrontend]

when refcount drops back to 0, the observable should go back to the cold state which means that the http call should be executed when a new subscriber arrives later

[@kramatanga]

is not bad to use nested subscriptions ?

[@DecodedFrontend]

Usage of nested subscription is absolutely fine and you can not avoid it actually because very often our stream might depend on the value from other one. Just make sure that you use proper operators for that (e.g switchMap, etc) instead of doing obs$.subscribe(val => obs2$.subscribe(...))

[@Doktornikita]

I like it.

[@Xandrios93]

using this approach takes the "complexity" of those frameworks away, because it shows, there is no black magic involved. So taking this approach might be the right thing

[@radvilardian740]

humm, takeUntil before shareReplay won'tbe useful here?

[@DecodedFrontend]

Thanks for your question. takeUntil + Subject would help, this is true. However, there are a few reasons why I would not do this: - takeUntil pattern requires more boilerplate because it needs additionally a Subject and onDestroy hook where the Subject has to emit destroy event. You can suggest usage of the takeUntilDestroy operator which is only 1 line, but it will be a one-line-solution only if this operator is used in the constructor/injector context. Otherwise, you have to inject destroyRef or injector and provide it as an argument value for takeUntilDestroy. - takeUntil + Subject and takeUntilDestroyed operators have also pitfalls that might cause memory leaks and you have to always care about the position of takeUntil in the operator chain. I covered it in this video - kzbin.info/www/bejne/m3vWZXiAirShhKcsi=Dqkn1-cmB2BjS_0s 3. takeUntil + Subject solves automatic unsubscription as well as the AsyncPipe, so to me, it is simply confusing to see additional unsubscription logic for the observable managed by async pipe.

[@radvilardian740]

@@DecodedFrontend nice, takeUntilDestroyed is a good choice I think, and yeah better use it in the injector context, that's why i like to use declarative approach for the rxjs. Thanks.

[@mansoorabdullah]

If the subscriptions cause memory leaks, why Angular can't destroy it by default when onDestroy the component. It's a headache for developers to find the memory leaks

[@DecodedFrontend]

I think this question better to ask angular core team :) But yeah, I understand that this is quite annoying to always keep in mind the memory leaks.

[@sergiim5601]

[@hunnidbands100]

Refcount 0 should be default behavior

[@ratg97]

takeUntil 1 line

[@DecodedFrontend]

Take until also has its own pitfalls :) You can check it out here - kzbin.info/www/bejne/m3vWZXiAirShhKc Also, takeUntil should be used along with Subject and ngOnDestroy hook which is already more then 1 line :)