How to handle errors REACTIVELY with the async pipe 

As a temporary workaround, you can use the shareReplay(1) operator in the pipe of the original source to avoid triggering the cold observable each time a subscription occurs.

@@cheatman05 yep agreed (as long as you remember to also enable refCount as well). This video's advice can be used effectively with multicast observables, but I imagine that this video has led a lot of people down a painful, confusing path since it came out.

Thanks for the example. Usually everyone is praising async pipe, without showing error handling AT ALL. I got to say I am not really convinced though. It's just so BLOATED and easy to get wrong (like if you forgot the shareReplay and fire multiple requests). Your github example has like 35 codes dedicated to just handling one simple async function and it's potential errors. I'd rather subscribe manually and handle next and error myself, that's like 10 lines of code AT MOST and pretty much zero room to fuck up. Also seems so much more more readable - though I get that a declarative coding die-hard might drop dead from shock when seeing such blasphemy :)

@@Matrium0 I'm not a fan of this strategy (tons of foot guns) , and I agree in isolation a subscription isn't a big deal... until you have like 10 of them and they start having short transient lifetimes... at which point congrats you've reinvented callback hell

Signals to the rescue

Hi! I think this would not be the same since combineLatest won't emit until all the streams it contains emit, therefore the template in the video should be changed, and the logic can become not so clear. You could add startWith(null) for each of the combineLatests streams to have exactly the same behavior, though

A util function or error handling service could do this nicely for you

Is there some specific problem you face in regard to this? Let's say the getUser method is actually a getList method that returns a stream of an array of items that we display in the template. If we wanted to add an item then we would just do something like call addItem which would handle adding the item in the service, and then cause the getList method to emit the new data on that stream, which will then be picked up by the subscription we already have.

@@JoshuaMorony Right. That makes sense. Especially if you are using a state management lib or the (Behaviour)Subject pattern. My approach involved trying to append/delete to the response from within the template or component instead of emitting a new response from the observable in the service

@@shemmuthanga6352 Can you give me a specific scenario (e.g. you have an array of items, you are displaying that in the template, you want to add an item to the array - why is it that you want to add an item but not to the source observable/what do you want to do with it etc) and I might be able to give some advice on doing this in a reactive way :)

@@JoshuaMorony ​ OK. Let's say you have an api which you pass a number to fetch paginated data. e.g /api/posts/1. Page 2 will be /api/posts/2, etc. Page 1 will be initialised in the ngOnInit hook . How would you fetch and append the next page results, reactively :) e.g through infinite scroll event or button click. The response for each request will be something like {success: boolean, results: [posts] }. I hope I am comprehensible enough.

@@shemmuthanga6352 Cool that makes sense - so in this case what you would want is a stream of that page number changing. Maybe you have a reactive form set up to handle the page input and then you utilise the valueChanges stream for that input. That will be the stream you subscribe to with the async pipe in the template, but of course we don't want to display the page number we want to display the data for that page number. So you pipe on a switchMap operator to that valueChanges stream - this will allow you to take the value from valueChanges, but pass it into a new observable stream instead. You would have the switchMap operator return the observable stream from the http request that fetches the data from the API (and that switchMap operator will have access to that page value from the original stream). Now every time the page number changes, your stream will emit the new page data. This probably would make a good video so maybe I'll do it!

I use NgRx Component Store for these sorts of scenarios - if you're not familiar with Component Store specifically it is a much more lightweight solution than the full NgRx Store. I have a video on doing pretty much this scenario here: ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-gYzAhW_glqc.html

There are two separate streams: user$ and userError$ and they are each being subscribed to once.

@@JoshuaMorony if these were http requests would there just be one http request for each user even though there are two streams/subscriptions?

@@ytamb01 this is a good point to bring up - by default there would be two separate requests. So if you were getting an API with an Http request I would make sure to have the service (e.g. from the getUser method) set up a hot observable (e.g. cache the observable stream using a class member in the service, and use shareReplay) - this way both streams would share the same data emissions and the GET request would only be performed once.

@@JoshuaMorony Thanks. I'm never sure when sharing streams has this effect without watching the network tab!

@joshua morony, how would you cache the observable if there's an input paramter to getUser like userId?

Is there a particular reason you prefer shareReplay in this instance instead of creating a vm? shareReplay would deal with the issue of creating multiple subscriptions, but what I like about the vm is that I can just use the async pipe in one place rather than having to use it every time I want to use the value (just from a syntactic perspective).

@@JoshuaMorony shareReply is straight forward. vm looks like a hack and need explanation, it isn’t understandable when reviewing the code

@@natqe4049 thanks for your perspective, I do disagree on it being a hack though. Using a vm is a pretty common Angular pattern, and I'm creating it directly in the template here but you can also just create a single separate vm$ observable in the class to clean the template up even more.

@@JoshuaMorony Hello! Can you show how vm$ can looks in this way ? In template I use now: *ngIf="{ channels: channels$ | async, error: channelsError$ | async } as vm", so if I understand correctly it can be just: *ngIf=" (vm$ | async) as vm" ? But I dont understand how to build vm$ in class in this case. Thanks!