Should we really NEVER subscribe in Angular apps? 

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

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.

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.

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.

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

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.

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.

Why are developers "afraid" of subscribing manually?

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

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.

Really helpful content please continue

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.

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!

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

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?

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 ?

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.

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

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

True engineers have no problem writing and reading imperative code.

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.

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

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...

Good film. thx

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

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?

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?

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

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.

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.

what is effect?

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

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

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

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.

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.