Reactive Error-Handling in Angular | Maria Korneeva | ng-conf 2021

[Music] hello everyone my name is maria coniva and today i'm going to talk about reactive error handling in angular i'm going to touch upon some eric's jazz operators error handling strategies different error types and the ways you can handle them let me introduce myself i work as front-end technology lead at alleris solutions or a small company based in germany providing digital solutions for our clients in my spare time i like discovering new places and writing articles for ngconf if you have any questions feel free to drop a line by email or on twitter or linkedin let's start with our topic why are handling in the first place we write web applications that run a client side so we cannot be sure what hap what really happens there but what we can be sure about is that whatever can go wrong will go wrong sooner or later so we have to be prepared for this oh um i'm sorry well kidding that's just to prove a point that aries can have can happen anytime everyone can write web applications but if you want to stand out you have to write applications that provide great user experience and error handling is part of it additionally if you don't handle errors at all and just lock them on the console you might give away too much of implementation details that can be used against you by hackers and of course we want to improve with every single iteration so we have to know what happened for this we have to lock and track our errors so that we can optimize our software with every single release so let's have a look at errors and error causes since our applications run in the browser we might face internal errors usually javascript errors such as unhandled promise rejection on the other side our errors might come from outside such as http error responses and sometimes we have to deal with some things that that are not technical errors per se but are considered as errors by the business side for example negative values in the age input field in my presentation i'm going to focus on external errors because they are the most unexpected ones we cannot control them and yet we have to be prepared so let's have a look at the different error classification first of all you might face validation errors and i'm not talking about client-side validation which you have to implement in the first place but about the server-side validation errors for example um postal code ctms match the second type are the known classical errors something like um the server is not available you might also have to deal with silent errors those are errors that the user doesn't care about he or she wouldn't just notice and the last but not the least unexpected unexpected unknown errors they still can happen let's have a look how to deal with them first of all in case of a validation error be specific as specific as possible and give your user the chance to change the input so that the second request is successful if the server is not available you have to inform the user what went wrong and provide some solutions some plan b maybe um to suggest to fill in a form and send an email if it's a silent error or the the error that the user doesn't care about maybe you failed to display some advertisement or some banners some teaser or something just go poker face don't display anything in the ui and how do you expect the unexpected well you just have to provide a fallback scenario for all the other areas that you haven't thought about let's briefly talk about the reactive part of my topic in the reactive programming everything can be considered at the stream of data philosophically speaking writing a web application is nothing but just moving around data so you push your data and you have to react upon it instead of pulling it and acting in the imperative programming so in this respect errors is nothing else but an undesired interruption of the data stream and error handling is nothing else but the attempt to restore this data flow [Music] with this being said let's move on let's have a look at some eric's chess operators we'll start with catch error because this one is the most relevant one for error handling it catches the error and then we can decide if we would like to return a new observable one to rethrow the error if we decide to return a new observable the so-called catch and replay strategy then we can make use of our next operator off operator it is not specific to error handling but in our use case it helps us to wrap the default value as an observable and return it let's have a look at our marble diagram the error happens here we catch it and then replace by the default values that our off operator provides it can be null or any other value that you consider as meaningful if the service fails let's have a look at syntax catch air expects a function as parameter and this function itself takes two parameters error and source observable it returns the so-called operator function which is either the source observable or any replacement for it for example our observable with default values so what you can do is to return the source observable and then re-subscribe to it implementing the basic retry functionality you could also return error and pass it to some error handling method or you can delegate the whole error handling to some other service method let's have a look at the last use case so let's say handle error is our error handling method we can even pass some parameters in here for example an error message that i would like to display this method returns another method which takes a response as a parameter and returns an observable in here we can do whatever we would like to with our air response tracking logging sending some notifications but we have to return an observable at the end in our case it's just null because this is our default value here are further eric's js operators for error handling for example you can use throw error if you need to propagate the error and need to handle it in your component that would be catch and rethrow strategy the marble diagram for this is very simple retry and retry when help you to increase the success rate of your requests however with you still have to decide what you'd like to do with your error if it happens again to replace it or to rethrow it now we're ready to have a look at the code known validation errors um let's say you have just a basic form with one input field with some error message and a button so what you can do is um you can use catch error rxjs operator and check for the validation error status code which in my case is 422 and then you just set its validation error to true and display your your error message you can handle other errors here too but just imagine that you use send form multiple times across your application then you have to duplicate or copy paste your code which is never a good idea i think we can do better than this let's have a look first of all you can use http interceptor provided by angular so you just implement the interface and the nice um thing is that you can retry your request which is really user friendly you can again use sketch error for this and within this method you can could refresh token is if the user is unauthorized you could even differentiate between javascript errors and http air responses because you need to handle them differently when you track them because they have a slightly different stack trace however this solution has a drawback you cannot be really specific about the requested field so imagine you have three requests in your application for storing personal data contract data and bank details you cannot provide a really specific error message if just one of them fails so let's have a look at a different solution so we can put our error message in the separate component error component in our case which is just a red text and subscribe to the notification of the area notification service then we can just display whatever we get from the service in our component our error notification service looks like this it's just a simple behavior subject and in our service we can just call next on this notification and provide the specific error message which which then will be displayed in our error component with this solution you can be very specific about your requests however imagine if you have to lock and track your errors as well so you will repeat this part of your code over and over again so we can do better than this so let's introduce error handling service in handle every method you just can provide additional functionality in my case i want to handle known errors differently so my known errors are 400 401 and 403 in this case i want to display a specific error message in my error component and if something unexpected happens i want to implement a different behavior for example a redirect to an error page but you can have um tracking logging whatever you want in here so you can use this service as follows you just call handle error and pass the very specific error message and the rest is being handled by the error handling service so next type of error silent errors let's say you want to load some banner and it fails the user doesn't know that the banner should be there so if it fails an error message would rather confuse him or her than help so in this case you just don't show anything on your ui and you just can return null as if the service is up and running and doesn't return anything the last but not the least unknown errors angular provides a default error handler which just locks your errors on the console however it's not the best way to handle your errors in production because again you might give away too much of implementation details that can be used by hackers um additionally you might still want to log and track your errors and in your error handler and finally you might implement a unified behavior for all the unexpected errors such as redirect to an error page your custom implementation of error handler could look like this you just extend the error handler override the handle error method in my case it just redirected the error page but you can add any other functionality don't forget to provide it in your ng module and you are done well not yet don't forget about testing here are some code examples and just if you'd like to test error handling in your component you can just mock service method that might return an error and mock throw air don't forget to subscribe in your component method though if you'd like to test error handling in your service you can flash http service response and place your expect statement in the error function now the tricky part how to test error handling in your error handling service you can create http air response throw it catch it and then call your handle error method just like consuming services would do you can expect all the internal implementations in here whoa we've covered a lot so basically error handling can be represented as a set of sieves of filters to filter out all the possible or unexpected errors so that it's always sunny in the user's world that's what i consider a great user experience however eric handling is by no means a justification for bad ux so if those errors could happen in the first place that's you who is to blame so first of all you have to eliminate all those loopholes for those errors and only then provide support if something goes wrong thank you for your attention and happy error handling

Channel: ng-conf

Views: 2,343

Rating: 5 out of 5

Keywords: angular, angularjs, javascript, ngconf, ng-conf, programming, angular conference, ng conference, angular javascript, angular tutorial, Javascript Tutorial, Programming Tutorial, Computer Programming, Google Angular, Google Programming

Id: qOH9XsN8aEs

Length: 14min 37sec (877 seconds)

Published: Fri Sep 24 2021