Thenin my application, I set the HttpClient up with an interceptor to automatically add some required headers to each request. Interceptors are one of those powerful features that buy you a great amount of flexibility when using the HttpClient. So, I decided to modify my interceptor slightly to also report progress via nprogress.
As @huochunpeng quite rightly points out, there is another feature of the HttpClient which makes this even simpler. The HttpClient has an isRequesting property to maintain the state of when requests are being made. So, a more elegant way to implement this logic is to create a custom element, like the loading indicator from the app contacts sample -contacts/blob/master/src/resources/elements/loading-indicator.js.
Great work Sean - just something that you might like to consider:
#1 if there is more than one concurrent request, then the first response will mark the progress as finished, even though others are still waiting. You could perhaps increment a counter on each request, then decrement on each response, and set the progress as done only when the counter is 0.
#2 do you happen to know if the response callback occurs when there is a timeout on the HttpClient?
We use aurelia-fetch-client extensively to add special headers for Auth purposes as well as to return a more User friendly error messages when there are errors instead of returning what the backend returns which may be more developer-friendly rather than user-friendly.
We also reject calls before we even make the request if there are things missing, e.g. POST requests with no body. Or if the user is not currently logged in yet, we reject it unless it is a public endpoint. This saves a lot of requests to the backend which we know will be rejected anyways.
Nice, I particularly like the ideas for intercepting the error responses to return clean error messages, and optimising HTTP traffic by avoiding unnecessary calls to private APIs. I actually never thought of using it that way but it makes a lot of sense.
3a8082e126