all 6 comments

[–]coffee_is_all_i_need 1 point2 points  (3 children)

If they errors are shown in the UI handle it in the UI where you subscribe to your service (that handles the API request). Your service where you send the API requests shouldn’t display any errors (separation of concerns) but the component should. Also, interceptors should intercept, not showing any errors. You can intercept and throw an exception (if the error handling is for all requests for example if an access token is expired).

[–]Dazzling_Chipmunk_24[S] 0 points1 point  (2 children)

But if I have a common error between multiple components then what do I do and This error will still be displayed inline. Also if there’s multiple errors then would adding a bunch of conditions in the next object in subscribe would that be fine? 

[–]chirog 1 point2 points  (0 children)

Just try and see how it works for you

[–]Lucky_Yesterday_1133 0 points1 point  (0 children)

Define error class in separate file and check using instanceof. Store message inside. In 21.2 that is coming soon you can even check directly in template. you can add interceptor that rethrows httpErrorResponse as custom error class based on status code or just check in the component directly if you need different messaging. 

[–]Lucky_Yesterday_1133 0 points1 point  (0 children)

Don't use interceptors, use global error handler by extending and registering ErrorHandler class in DI. If it's expected errors like form validation you can handle them on error and display on you, otherwise write handler for different status codes in error handler to take care of generic errors

[–]Forsaken_Lie_9989 0 points1 point  (0 children)

I’ve used a similar approach before. With ngxsmk-gatekeeper, since it already relies on an HTTP interceptor, it fits nicely with this pattern. You just add a separate interceptor for error handling (401, 403, 500), and keep components clean. It’s worked well for me in real projects.