search

aurelia / http-client

A simple, restful, message-based wrapper around XMLHttpRequest.
MIT License
62 stars 59 forks source link

http-client should create xhr hook to support cross cutting features #157

Closed bowczarek closed 7 years ago

bowczarek commented 7 years ago

I'm submitting a feature request

Hi guys, fisrt of all tyvm for the http-client, we've been doing great by using it in my current project instead of the fetch client since we still miss some important features there.

However, I came to the conclusion that there's something missing in the http-client as well or it has been never considered in the implementation or design.

What I mean by that is the fact that http-client is built on top of XMLHttpRequest and just because of this design purpose, I strongly believe it should rewrite the platform XHR definition by creating some kind of abstract xhr hook. As an example, you can take a look at xdomain that does that in order to handle CORS requests.

I'm aware that it is considered not to be 'safe' etc but that would allow to use cross cutting features like interceptors across whole application. Especially with all existing javascript libraries. For example Kendo UI does not use http-client underneath. Instead all Kendo UI components are generating requests either by instantiating XHR or invoking jquery.ajax which is essentially the same thing at the end.

Having had that kind of xhr hook the interceptors could be invoked across all possible libraries used in the project, otherwise you need to rely on the fact that a particular library will support http-client, which I think is impossible.

Please give me your thoughts, positive or negative, I'll be more than happy to hear you out.

EisenbergEffect commented 7 years ago

I'm really opposed to monkey patching the browser unless it is to add standards-based features that aren't yet implemented. In this case, it means that by instantiating http-client we would be affecting unknown other pieces of code on the page, including 3rd part plugins or other libraries which make assumptions about the base platform functioning according to spec.

My recommendation would be that if you really want this, then fork our client and make the alterations you want. Then you can share that and people who are ok with that can use it instead of ours. Even people not using Aurelia might be interested. It's just not something we want to do as part of our core platform.

bowczarek commented 7 years ago

Hi Rob, thanks a lot for quick reply and sharing your thoughts. I appreciate your concerns about affecting unkown other pieces of code on the page, but I'm talking only about enabling cross cutting features that would eventually mean invoking some sort of callbacks. I don't consider this as a potential hijack or negative impact on other pieces of my code. After all, cross cutting feature should by its definition literally affect your whole code base/architecture vertically and you don't want to implement that in two or three or more multiple ways.

Thanks for your recommendation, there's a high chance we'll do that. If we do that then we will share that back to the community of course.

Cheers

EisenbergEffect commented 7 years ago

Forking and building it is the best approach. Best case, we can merge what you do into our implementation. Worst, case, you have a plugin that meets your needs and others may want to use it as well.