I ran into this pattern mostly because of the error handling. I could handle errors at the service level and then use a toast UI pattern or some kind of global level UI to display error but this app needed errors inline in multiple places within the UI. Because of this I was trying to find a way to reduce the amount of logic within the templates/components for error/retry messages.
In the app that I tried this on I had a generic service that abstracted away the boiler plate code you mentioned which helps some. I'm planing on writing up a small follow up post or add on to this that shows an example of making it more generic.
I see the advantage to normalizing http error handling as you've described, but I'm still skeptical that this approach to loading is generally applicable. It doesn't strike me as generally helpful to link the loading status to the error status (though it certainly might be in specific contexts), but I'll look for your follow up post 👍.
There are many times when I want to indicate something is "loading", without creating a specific error handler for that thing. For example, if I was lazy loading a component, I might want to indicate that something was loading while relying on a global error handler to trigger if the client happened to have lost their internet connection.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I like your custom pipe strategy! Very nice post.
I ran into this pattern mostly because of the error handling. I could handle errors at the service level and then use a toast UI pattern or some kind of global level UI to display error but this app needed errors inline in multiple places within the UI. Because of this I was trying to find a way to reduce the amount of logic within the templates/components for error/retry messages.
In the app that I tried this on I had a generic service that abstracted away the boiler plate code you mentioned which helps some. I'm planing on writing up a small follow up post or add on to this that shows an example of making it more generic.
I see the advantage to normalizing http error handling as you've described, but I'm still skeptical that this approach to loading is generally applicable. It doesn't strike me as generally helpful to link the loading status to the error status (though it certainly might be in specific contexts), but I'll look for your follow up post 👍.
There are many times when I want to indicate something is "loading", without creating a specific error handler for that thing. For example, if I was lazy loading a component, I might want to indicate that something was loading while relying on a global error handler to trigger if the client happened to have lost their internet connection.