Should we really NEVER subscribe in Angular apps?

[@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

[@OLIV3R_YT]

I think the most important thing is readability and to make it easy to understand for your team members. Even if that involves using "subscribe" instead of complex workarounds to make it fully reactive.

[@rd_45]

After watching this video, angular seems very complex to me.. till now i was learning happily by following angular docs

[@MoonShadeStuff]

@@rd_45 it was very complicated to learn Angular, since the Angular Docs really just provide some basic starting point and a bunch of advanced topics as „building blocks“. Understanding how it all works together, to learn and develop confidence that you’re following good practices takes years.

[@Rob34570]

To me, the best approach is to set the value in the second textbox like this: Where: public myObs$ = this.form.get('item1')?.valueChanges.pipe( switchMap(val1 => this.dummyService(val1)) ); This is declarative and does not rely on side effects.

[@valcron-1000]

This is the correct solution IMO.

[@BZValoche]

I wish I had read your comment before writing mine ^^

[@anthonyferreiramartinez6666]

This is definitely the way to go, this answer was not discussed in the video, you do not need to tap as a cheat, and you don't need to add stores and effects just to avoid subscribing.

[@valeron_1337]

But if we need to persist the results of dummyService call to fieldTwo inside the myForm we would still need to have this sort of side effect (probably adding another tap operator in myObs$)

[@NerdENerd]

Do not tap observables to set component properties. This is one of the leading causes of the exception value changed after onchange check. Subscribing is reacting, claiming it is not reactive is rubbish. If the data is used in the template use the async pipe, if not subscribe and make your code clear as to what it is doing. Do not jump through convoluted hoops to avoid subscribing, there is nothing wrong with subscribing. If the observable you are subscribing to such as the reactive form in this example is created in the component there is no need to unsubscribe. It falls to garbage collection with the component, we only need to manage subscriptions to observables the are still referenced outside the component after onDestroy. Everything in this video is an antipattern. Don't do any of it. Use observables as intended and just subscribe.

[@drago8701]

It's a good practice to unsubscribe if you imperatively subscribed. It can also be that garbage collection does not immediately dispose of the component instance and then it might still receive some events until it's finally gone. The subscribe callbacks might cause errors when the component is not alive anymore or might cause expensive operations (network request) that are not necessary anymore when the component is disposed.

[@NerdENerd]

@@drago8701 If the observable was created in the component then none of that is possible unless you passed off a reference to somewhere else which means it should have been created in a service and not the component. In the example it was a reactive form created in the component, absolutely no need to unsubscribe.

[@xucongzhan9151]

Yeah, I agree. Subscribing is reactive. It's just not declarative. Though in many cases, the observable gets introduced into a component via DI, and it outlives the component. The lifespan mismatch is often overlooked by new Angular devs.

[@brainoverflow98]

Hi Joshua, I'm new to your channel and I must say you are doing a really good work here. Not many front-end programmers are looking at their code at this level. I suspect it's maybe because most of them are self though developers who just focus on getting into a job but not care much about the quality of their work. And most back-end developers can't approach the front-end as they should. They just want to program as they've been doing for years. As a BE heavy developper myself wasn't also aware of the approaches you thaught me. But I was aware of the fact that something was wrong when you treat it the same way as your back--end code. So I made some reaserch and I found your channel. You are really utilizing the community by trying to look at a topic from different angles. Please keep it up for better front-end community.

[@alexcoroza4518]

I remember a discussion within our team about the usage of complex rxjs operators and the concept of "one stream to rule them all". We ended up using subscribe and made everything quite similar to how we code with Promises. The main reason is, our project is a long term one and developers come and go, we have the option to just hire a good javascript dev(or any dev that uses other framework) and train them with some basic rxjs. Would take something like a week for training and they are good to go and start working on tickets. Learning reactive programming has a steep learning curve and would take more resources. Also it is harder to find an Angular dev and would often have a higher rate than other devs that uses other framework.

[@basdfgwe]

I personally prefer to do a manual subscribe, it provides readability of the code.

[@its_vincesanity]

Why are developers "afraid" of subscribing manually?

[@CodingAbroad]

Great question. Everyone runs from it like the plague

[@JBuchmann]

I think because once you subscribe manually, you end the flow of the observable. You cannot compose it to create other streams. Or combine it with other streams (combineLatest), etc. And as a bonus you get the benefit of not needing to write code to unsubscribe.

[@MoonShadeStuff]

It’s what gets taught because it’s easier to say „never subscribe“ instead of teaching how to unsubscribe and even then, someone might forget to unsubscribe. But I think that using subscribe can be the best method in certain situations - just for people starting out, they should always try first to not subscribe because in most cases it’s avoidable.

[@cipherxen2]

True engineers have no problem writing and reading imperative code.

We've all been in these trenches full of mud, right?

[@brunoj0]

I think i also replied to this tweet :) . My case was similar, I created FormGroup based on stream from ngrx store which was than put in template using async pipe. Unfortunatly I couldnt find a way how to properly (reactive way) dispatch ngrx action on valueChanges. So the team agreed that in this case we will use subscirbe. After watching your video I think it wasn't a bad decision

[@bronzekoala9141]

I was getting started with Angular a month a go and thought I was beginning to understand it quite well. Then your videos come around and I notice I have grasped maybe 5% of it... Keept it up though.

[@Creationstree]

@Joshua, I am using a component store that has multiple properties in it and I am using a vm$ select(()=>{prop1,prop2, etc}) to share these props with my component as all my properties are observables, is it ok to use {{ (vm$ | async).prop | async}} or is there another way to handle this?

[@CraigShearer]

Great video Josh. Nice to see the thinking out loud. I think the conclusion is that there are no perfect approaches. One thing that springs to mind is how difficult it seems to be to see the effects of failing to unsubscribe. So, if you subscribe in a component and forget to set up a mechanism to unsubscribe when the component disappears, you're left with the subscription existing with no easily visible effect, apart from high memory usage when the apps been running for a long time, and perhaps some weird behaviour that's difficult to debug. If there was some tool to easily identify dangling subscriptions, that would be worth its weight in gold!

[@TheMikkelOLaursen]

I get the abstraction, but technically it doesn't make much difference. If you were to look at the implementation of the async pipe, you'd find they do pretty much the same thing; subscribing and returning the latest value, just in a pipe. Of course they optimize by making the pipe impure and using the change detector to mark for changes, but the technical principle of the event stream is still the same; subscribe and use latest value.

[@billy8461]

agreed

[@stephenpaul7499]

I would just bind the value of the second input to that observable using an async pipe... as you alluded to in the end.

[@JBuchmann]

I agree. It's so simple. And to make it less "magical" to other devs reading the code you can just add a short comment explaining how it's unsubscribed.

[@maximvoloshin7602]

Wonderful video! We really have to explore our options - this is the only way to find the best applicable design. Sometimes it also leads to hidden gems :) Please keep doing more such videos. Personally I prefer to avoid subscriptions whenever possible.

[@waldBestMusics]

Thx for you videos, could you also make a video, where you are using streams in an reactive way from the request from a service until the template with a lot of manipulations ?

[@billy8461]

i build my thesis with angular and ngrx. The app is almost entirely reactive but there are cases that subscribing is a must. My app needs to display a map with data. I use leaflet js and that requires to subcribe manually to the store selectors in order to get the data for the leaflet functions. So yea there are cases when subscribing is a must...

[@panchcw]

Really helpful content please continue

[@phuongtran-qh5kq]

Hi Joshua. 1 question, i created a login method with firebase, it returns a promise, then i use defer and from to switch the method to observable. When user clicks the login button then should id subscribe the method manually or is there any other way i can do to prevent the manual subscription? Thank you very much

[@BZValoche]

I would have set field two's value directly with async pipe, you do not need a side effect here. For example : And in the TS: field1change$ = this.myForm.get('fieldOne')?.valueChanges.pipe( switchMap( (val) => this.exampleService.getRelatedValue(val), ), ); This is more straigthforward IMHO

[@romarioputra3775]

Does the empty effect ways have side effect too? That is why i sometimes confused, because we dont subscribe manually, we tend to use tap() and having side effect. Whatdo you think?

[@jeffnikelson5824]

For me it depends on the complexity of the component/feature im working on. If I can Identify an obvious pattern where a few switchMap operators would to the trick then I stay with a truly reactive approach with no manual subscribe. It feels faster and less error prone. But in some cases there is so much stuff going on and so much complexity that you have to consider and think about Order of the logic or what populates what object at what time - Then in order to keep my sanity and keep my code readable for ordinary mortals I just do the manual subscribe.

[@jakehockey10]

This may not be applicable in all cases, but with this form, could the input value of the second field be bound to the observable derived from the first fields value changes with the use of the async pipe? Let the side effect do it's work in the template

[@psycho_amj_light]

Good film. thx

[@user-rp9iis1en6h]

what is effect?

[@habibhadi]

Overengineering in a nutshell. 😂 Thank you for the video. For me simplicity and readibility is more important.

[@joepfohl5259]

The real question is, how can I subscribe to your channel in a reified reactive manner? 🤔

[@JoshuaMorony]

You smash the subscribe button, it's the only way

[@joepfohl5259]

I’m not even going to takeUntil. Just gonna send it!🤣

[@omergronich778]

What about write operations? How would you avoid subscribing to post/put/delete operations without turning them into promises?

[@JoshuaMorony]

I don't think there is anything wrong with subscribing to trigger an observable in this case (nor in any case really, I just generally prefer avoiding it). But in my particular workflow, a post would be handled with a Component Store effect, so there wouldn't be a need to subscribe manually (Component Store would handle that)

[@omergronich778]

@@JoshuaMorony thanks :)

[@toxaq]

I realise this example is contrived but I would use a view model and a setter. Then you can avoid needing to overkill everything with observables. I would like to know how you use the httpclient with infinite scroll and avoid subscribing?

[@JoshuaMorony]

I actually already have a video on a reactive infinite scroll here: kzbin.info/www/bejne/m4nHYpeZl6aNidk :)

[@OlehBiblyi]

Hello, thanks for new video: 1. Chau is great ))) It's interesting to use component store effect, I am sure it can be useful with some complex logic, but not sure to add one more service for this case with only one effect. 2. Also agree with you about subscribe in the template for this case, not too clear. 3. For this case I would subscribe in .ts, but I would handle setValue in the "tap". 4. Have you tried *ngrxLet directive from NgRx?

[@JoshuaMorony]

No, I haven't actually had a chance to try out ngrxLet yet! I would like to play around with it though to see if it can improve the way I'm handling stream errors.

[@OlehBiblyi]

@@JoshuaMoronyGreat tutorial from Zack DeRose kzbin.info/www/bejne/gYHZm42YetiLa68

[@g-luu]

What an interesting topic. Well done. Chau solution seems to be the best for me too. Only downside to this is of course binded to that module it is implement in. I normally use C store globally to runaway from using the full ngrx way.

[@markmidwest7092]

What if I am using an https observable to populate session or local storage with user information from a web API, including a token? It seems fair imperative programming is a valid way to process API data and store user information in session or local storage.

[@JoshuaMorony]

I think that's a good example of where avoiding a subscribe wouldn't be necessary - you could if you really wanted to with the methods mentioned in the video, but I don't think it achieves anything. In this case, you need the data out of the stream to put into local storage, that stream isn't being used in the app/displayed in the template, so a manual subscribe makes sense.

[@victory_lucky]

Though still new to Angular, I'd prefer not to manually subscribe.

[@tntg5]

This whole debate is sterile. The most important thing is that you understand what you're doing. Rxjs is a set of complex tools to achieve simple tasks you can do with vanilla JS. What I noticed though, is that people who love Rxjs, tend to beleive that their approche is necessarily better than any other alternative. Which is kind of annoying. They spend a lot of effort to use as many operators as possible, when there is a simple solution sitting right there, and for no gain in performance or readability.

[@_djandrzej]

This is a terrible video that barely answers a question in title and doesn't explain why is the question even valid. In the first example you're still subscribing but through ngrx effect, this is making it less clear with no improvement for the sake of not using specific API. Next you're showing an example that you say is clean just to say minute later that it is not and you wouldn't recommend it. And for the final example there is actually no example since we're back to square one - using subscribe.