The secret to understanding piped operators in RxJS (Advanced)

[@JoshuaMorony]

Join my mailing list for more exclusive content and access to the archive of my private tips of the week: mobirony.ck.page/4a331b9076

[@fullstackburger]

Hey Josh, keep up the amazing work! I work with Angular all the time and Im still learning a lot of valuable information from your videos. They're great quality and always easy to understand.

[@mohammadjabr7780]

This is the best free software Ive seen. Respect.

[@kanstantsinmalikau7598]

great approach with drawing and explanations, I could understand everything without stopping video, thanks!

[@kingsleyokeke6021]

Massively helpful video. Thanks Josh

[@dafengxu3875]

Very high quality video! Thanks a lot!

[@CeezGeez]

nice way to look at it, thanks

[@subashbarik]

Great explanation. Nice to know this.

[@mvip4927]

IT'S ALWAYS THE UNDERRATED VID THAT'S LEGIT! THANK YOU!

[@andriisavchuk9822]

Awesome explanation!!!

[@sarachal7579]

This was so helpful!! Thank you

[@additionaddict5524]

You should do a RxJs course. I’d happily pay £100 for 4 hour course similar to universal courses

[@rounakkalsii9541]

+1

[@stefanvukasinovic5962]

Nah fck that make it +100 i speak for the mass like if you want it

[@davidontiveros2895]

Awesome content as usual !

[@pchasco]

After having drunk the RxJS operator Kool-aid for some time, I have found that RxJS operators make my code more difficult to debug, unit test, and reason about. This is especially true when incorporating operators that combine streams.

[@farkhodoff_tech]

Bro you are best

[@gaborkonstanzer4237]

So, now you know you should just put the StartWith op. at the end of the pipe and you don't need to concatenate the default value in front of the source stream, like in the last video. I reckon that's where this is coming from? :) Good explanation, really liked this approach of following the subscriptions.

[@JoshuaMorony]

I actually don't 100% remember where this showed up initially, pretty sure it was for the Giflist stream that I have indeed talked about in another video

[@nikolitilden8224]

Love the video! Clear and concise, even though sometimes RxJS operations can be very confusing. Also, what is on your terminal background? Are those Vim commands and how did you get them to show up on your terminal background?

[@JoshuaMorony]

Ha, yes! Trying to improve my vim skills - it's just an image I've set as my iTerm background but the trick is to have them display through the vim editor (you have to configure your theme to have a transparent background so that the terminal background shows through)

[@easy-draw]

Nice video once again. Just a question do you really need of() operation on the switchMap line ?Since it is alrady observable.

[@JoshuaMorony]

Yes, the concatMap is subscribing to the switchMap and the (photo) value is just an individual photo value, I need to return a stream of that one photo value which is why of is used there.

[@dlemb]

And when you have a filter operator inside? Still subscribed to the last one?

[@JoshuaMorony]

Yes - you can think of the filter as subscribing to the operator above it, and then returning a new stream that will only emit items from the stream above that satisfy the filter condition

[@syedaligll7474]

thank you!!! video liked and u got a well deserved sub from me!!!!

[@JBuchmann]

Cool video, but I think it just made me a bit more confused, haha. I have a possible video topic idea... This situation comes up for me all the time and I'm sure I'm not using RxJS correctly: To avoid subscribing to an Observable I do the usual piping, and have that assigned to something like myObservable$. I can then async pipe it to the template. BUT very often I also need the result of that in my TS component code (for whatever reason). To do that, inside the pipe, I use the tap() operator, and in there assign the value to a local variable in the component. Then that variable can be used in some TS logic. But this feels so dirty, especially since I feel forced into doing this very often. I feel like it would be cleaner if I just subscribed and then in the "done" block assign to my local variable. (then deal with a manual unsubscribe). Is what I'm doing considered "okay"? Is there a better way? I think this would be an interesting video topic. :)

[@JoshuaMorony]

"To do that, inside the pipe, I use the tap() operator, and in there assign the value to a local variable in the component." - As I think you've correctly identified, this is the source of the problem/awkwardness. What is happening here is you are essentially trying to pull a value out of the reactive world and do something imperatively with it - in other words, you are mixing two different paradigms. The clean solution here would to figure out how to do what you need done reactively, or otherwise likely just explicitly subscribing and doing what you need (which is also not "reactive" but it is being more direct about it). What you could do depends on the situation, feel free to elaborate a bit more on your specific situation if you like.

[@JBuchmann]

@@JoshuaMorony Thanks for your reply! My situation is prob too difficult to explain, haha. But what I can say is... I have an overall pretty complex and reactive component. I refactored it so it's as reactive as my skills allow at this time. I have Observables that pipe into other observables, and those pipe to others. (I guess that's called "composing" observables) If I subscribed everywhere then I couldn't do the composing of the Observables, as once you subscribe you kill the flow. (as I understand it). It's just annoying in some places in the component code it needs the current value of the observable. So the only way I know how is to "tap" it out into a class variable. I suppose if ALL my component logic was inside pipe operators then I wouldn't need to tap anything out. But I don't think that's a reasonable expectation to have to do. Oh well, I'll keep on practicing. 😀

[@d.sherman8563]

@@JBuchmann You could also access the value by passing it into a child component as an input.

[@culttm]

How could you implement a loop in this case?

[@JoshuaMorony]

Depends what you mean exactly, can you elaborate?

[@culttm]

​@@JoshuaMorony i mean the infinite loop as a carousel. After ending play again

[@JoshuaMorony]

@@culttm I haven't tried it for this example, but the 'repeat' operator should work for that

[@culttm]

​@@JoshuaMorony would you try?)

[@kumarsamaksha7207]

Google - There goes are secret.

[@zoltanboros8963]

Not you're weird, but the syntax. Anyway, multiple nesting is nowadays spaghetti code.

[@tntg5]

I still beleive promises are much more cleaner and clearer

[@JoshuaMorony]

I don't want this to come across as antagonistic, I don't think everyone should like and use RxJS and there isn't really a right answer here! But, this is a pretty complex scenario that I think the operators (though certainly not obvious/easy to follow) make easier. I haven't tried a Promise based solution for this, but creating a Promise based solution to: - Take an array of photos as an input - Set those photos one at a time on a class member to display in the template with a delay - If a new set of photos is received, forget the old ones and switch to the new set instead - Pause/play the changing of photos in response to an event Would highlight the benefit of the RxJS/operator approach I think.

[@tntg5]

@@JoshuaMorony True, there isn't one right way to doing things. The right one is usually the one the developer understands best.. and can test. Now, for someone who have never seens either of these 2 solutions, the promise based one would seem self explanatory compared to using rxjs. Having said this, I would like to thank you for the quality of your content, and your dedication. I have learned Ionic alongside your journey. So this isn't a criticism

[@JoshuaMorony]

@@tntg5 To be clear, the example I outlined in the comment is what the stream in the video is doing

[@CheesyOfCityOfHeroes]

Spot on, rxJS is a huge over complication of basic engineering principals, I've lost staff due to this nonsense.

[@bryangomez5951]

@@CheesyOfCityOfHeroes God, I don't know what kind of programmers would quit just because of Rxjs. Or maybe the people that were in charge of explaining it to the new developers didn't know the topic very well..