Is this how we will handle errors reactively with signals in Angular?

My modern Angular course: angularstart.com/
In this video we investigate the relationship between RxJS and Signals in Angular apps, and specifically a technique we can use to handle errors that is reactive and declarative.
RxJS reactive error handling: • How to handle errors R...
Source code: github.com/joshuamorony/signa...
Implementation of toSignalWithError: github.com/joshuamorony/oss/b...
Get weekly content and tips exclusive to my newsletter: mobirony.ck.page/4a331b9076
Learn Angular with Ionic: ionicstart.com
#angular #signals #rxjs
0:00 Introduction
0:13 Pre-signals approach
0:39 Post-signals approach?
1:27 Error handling
1:57 The solution
3:35 Helper utility
4:35 Conclusion
- More tutorials: eliteionic.com
- Follow me on Twitter: / joshuamorony

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

[@stevenrobson]

Clean intuitive approach. I see this becoming a common practice.

[@CorentinClichy]

Always qualitative and well explained stuff ! Thanks a lot !

[@briancepon6402]

Very nice way of keeping things reactive as they evolve ! thank you !

[@andresmauriciofajardoolaya2721]

I like this approach that you mention :)

[@julienwickramatunga7338]

Nice approach, clever 👍

[@Blafasel3]

I love the approach! Its basically the Either pattern in a reactive way :) the helper function should make writing stuff like this much easier.

[@scottfwalter]

Love this approach!

[@AlainBoudard]

Pretty clean pattern I think ! Nice catch 🙂

[@Sevkingblade]

This approach is nice. I like it

[@joeyvico]

Nice Joshua! Thanks

[@danielsmeyer]

I think it's a neat approach. Will test today. 😊

[@endlacer]

And what about a retry-button for example. After it the rxjs-stream (getFromApiError()) errors, isn't it "dead"? how would you go about implementing a retry which results are delivered in the same rxjs stream?

[@JoshuaMorony]

I haven't played around with patterns for this use case yet though a retry button isn't something I've commonly done. I would more likely have the retry as part of the RxJS stream, and then if it still ultimately errors that could be handled with the signal (of course, there are lots of different situations calling for different approaches)

[@endlacer]

@@JoshuaMorony >isn't something I've commonly done yeah i thought so. most rxjs examples found in videos do not address this. it's required for every rest-call in our team, though. (video idea? :D reactive retry button which feeds into the same stream of the first try (async pipe in template))

[@JoshuaMorony]

@@endlacer I haven't considered how to get this to play into signals, but I do have a public code example which I think should handle your use case, see here: github.com/joshuamorony/refresh-app/blob/b0425644f8b4d818c526cf4eab9f9320138042dd/src/app/clients/data-access/clients.service.ts specifically the retryWhen approach. In my case, I am "restarting" the stream when the user logs back in, but you should be able to use the same concept with a retry button (just have the retry button next some subject in the service instead, and use that for your retryWhen).

[@endlacer]

@@JoshuaMorony omg, retryWhen. why didnt i know about this one? i hacked together something like retry$.pipe(startsWith('anything'), switchMap(_dontcare => _donecare.pipe(your actual stream)) thank you very much :)

[@fabianvieri1907]

Clean approach!. I want to ask how do you handle for mutation request that can be called multiple times using signal?

[@HarveyDaclan]

I like the approach! Very clean and straight forward. Thanks! Do you know if we need to unsubscribe a long running observable inside a toSignal function?

[@JoshuaMorony]

No toSignal is a lot like the async pipe in this way - once the context in which the signal subscribes to the observable (via using toSignal) is destroyed then the subscription will automatically be cleaned up.

[@piotrsobus9340]

This is a pattern that I have been using for quite some time and it's pretty handy. You can also use materialize operator instead of map + catchError.

[@JoshuaMorony]

I actually used materialize for the initial implementation but found it to be more awkward than map/catchError - if you have a materialize example you could link to I'd be curious to see other implementations

[@RobertKing]

Looks good. Reminds me of ngx-http-request-states npm lib but for signals instead of vm

[@Billiam112]

Getting kind of async/await/promise handling vibe from this. :)

[@windmillcode9189]

async await is bad for your application always use obserables, transform promise to observable with rxjs defer and rxjs from

[@NoName-1337]

Your solution is a little bit like a "Result" in Rust. Looks nice.

[@JoshuaMorony]

I hope to get a chance to dive more into Rust at some point

[@chaos_monster]

I would love to start a discussion about the usage of services in the template. I am probably old school and would argue that everything injected should be private and therefor not directly accessible in the template About your video - I really like the thoughts and approach you've taken and would currently also tend to go that route

[@JoshuaMorony]

You can also mark the service as protected if you want - which makes it private but still allows access to the template.

[@chaos_monster]

@@JoshuaMorony That's true and I am happy that protected is "now" available in templates, but I think it's a more general question of should injected services be accessible in the template?

[@endlacer]

@@chaos_monster why wouldn't they be? no point to make stuff more complicated than they have to be just for rules sake

[@dany5ful]

​@@chaos_monster "- If the call is costly you would run it on every re-render" isn't this true for everything and not just a service tho? If you write some code on the component that is costly and call it in the template every render is going to call it... But if you do things right then it shouldn't be a problem, one example I can think of is using shareReplay to only do an API call a single time, then when you subscribe to it in the template it's only going to do the call 1 time, this could be in the component or service, doesn't matter. (the difference with the service obviously is using across multiple components.)

[@chaos_monster]

​@@dany5ful You're right that the argument is not only valid for service methods. You said one thing that highly resonates with this "if you do things right". That IMHO is the key to way to follow patterns, best practices and so on. Because sometimes you don't know what is right or you just can't remember or you forgot a detail and are in a hurry. I think the underlying train of thought for the "costly re-render" argument as well as for most other arguments against services in templates are around the idea that implementation patterns (probably) never exist to improve performance, but as a kind of contract for developers to protect from accidental misuse and provide a way to communicate the usage between devs, teams and even across companies.

[@PieJee1]

I used similar structures before signaljs was a thing. Not for signaljs but more for fellow developers having a hard time reading rxjs pipes.

[@cloudsss83]

You are a legend, mate. Any plans for a promotion of Ionic Start? Help your fellow Brazilians lol

[@JoshuaMorony]

No plans at the moment I'm afraid! I generally only do promotions for initial launches or big updates

[@lucasgiunta8874]

How to manage with this package the case of different error management in a stream who includes multiple call trough switchMap operator ? Like if something, stop the calls and display a banner, if something else retryWhen operator ?

[@JoshuaMorony]

This package is just a very simple helper, for more advanced cases you would implement whatever error handling strategies you like with RxJS as normal (and ultimately if your stream might still error without it being caught you could still use that stream in conjunction with toSignalWithError)

[@kapobajza3708]

Isn't there a drawback to this approach if you want to show the data and the error at the same time? For example if you have already fetched your data once and then an error occurs the second you fetch your data, value will be undefined. Therefore you won't be able to display your data and the error simultaneously.

[@Blafasel3]

That would be the same with obsevables as far as I can tell. To reach the scenario you mention you would have to store values one way or the other. But mostly displaying data only cares about the last result.

[@JoshuaMorony]

That's a use case that the original RxJS only approach (with two different streams) satisfies, and I think this could be modified to do that (have the last successful value cached). I might tinker with that a bit.

[@dimitritsikaridze6220]

why did you switch to neovim?

[@g-luu]

i’m also curious…

[@JoshuaMorony]

Lot's of little things but the biggest driver was vim motions/commands - I was primarily using the keyboard with VSCode and navigating around just felt a bit clunky. I started using vim bindings in VSCode which was pretty good, but it was a bit buggy/irritating so I decided to just go all in and commit to learning how to use neovim directly (which then also comes with a bunch of benefits around customisation)

[@AlphaFrog1021]

would be nice if you shared your config

[@JoshuaMorony]

@@AlphaFrog1021 I have a repo here: github.com/joshuamorony/nvim

[@Szergej33]

This is a good video and nice explanation. Creating a NPM package for 20 lines of code that can easily be copy-pasted is everything that's wrong with the JS ecosystem though :D

[@cosmokenney]

You lost me at of(null)...

[@user-hs9uf8fg5k]

yur method do not work with update, mutate etc. it is fail

[@JoshuaMorony]

It isn't intended for that - we're trying to get the value or error from an observable stream which is the source of the data, if you want to provide a second source of data (e.g. manually updating/mutating) then you should probably do something like setting the resulting data on some other signal or combining a separate signal/stream in some way.