Bug: Async XHR Response about requestly

[anlinguist]

@wrongsahil any ideas on this? Async fetch works no problem but I can't get async xhr to work properly.

[wrongsahil]

Hey @anlinguist. Sorry for the delay in response. Currently, we only support async code in requests triggered using fetch. XHR isn’t supported at the moment.

We're discussing and testing a potential solution to enable support for XHR as well. We'll keep you posted on any developments.

[anlinguist]

hey, thanks for getting back to me @wrongsahil. For my purposes, I was able to proxy and monkey patch XHR to allow async operations on the XHR response data.

In short, my approach pauses the original XHR request before it is sent, creates and runs a fetch request from it, takes the fetch request response and freely applies async operations on it, resumes the original XHR request, and overrides the XHR response using the now available response from the fetch operation. Here's how I did it:

1. Save a reference to the original XMLHttpRequest object and its methods (send, open, setRequestHeader).
2. Override the global XMLHttpRequest object with a custom constructor function.
3. Inside the custom constructor, capture the request details (URL, method, headers) by overriding the open and setRequestHeader methods and storing them in a requestDetails object.
4. Override the send method to defer sending the request. It attempts to retrieve a response rule based on the request URL, request data, and method.
5. If a response rule is found, it enters an async logic; otherwise, it sends the request as-is.
6. In the async logic, a separate fetch request is made to the original URL using the captured request details. The response is then modified based on the response rule's modification function, if specified.
7. The modified response is stored in a responseOverrides object, and getters are defined for the response, responseText, status, and statusText properties of the xhr object to return the modified response.
8. Finally, the original send method is called to resume the original XHR request, but with the overridden response properties returning the modified response to the caller.

Of course, this approach does make an extra request to the original URL in order to fetch and modify the response data. This additional request may have performance implications, especially if the response modifications are extensive or if there are a large number of XHR requests being intercepted. For my purposes, this is acceptable.

[lazyvab]

@anlinguist If API request is not idempotent in nature, firing it multiple times may lead to unexpected results. For instance, a POST request which creates new data on server may create it multiple times.

[anlinguist]

@lazyvab Yes, that's true, so for many usecases, it may not be an ideal solution. If the request you're targeting is an XHR and ends up creating/updating/deleting data on a server, this would not be an ideal approach.

However, if the request you're targeting is for obtaining data from a server, it works. For my purposes, this was an acceptable workaround - I have rules around which XHR requests duplicate the request using the fetch request approach, and all of my rules really focus on getting data from the server rather than posting/putting/deleting/etc.

Due to the synchronous nature of XHR's readystatechange, I could not figure out another way to perform asynchronous logic directly on the XHR request.