XMLHttpRequest: Ensure events order according to the specification about interceptors HOT 3 CLOSED

Hey, @alfdocimo! Thank you for your interest in making this library better!

This change is done solely in the mocked response context, as we're propagating the listeners/callbacks in case of the original request to that original XMLHttpRequest instance.

You're right, we should dispatch the loadstart as soon as we start handling a mocked response. Ideally, after this if statement:

https://github.com/mswjs/node-request-interceptor/blob/50e5aa72ee102a8bec8e2f38e3efc9efa26d5e74/src/interceptors/XMLHttpRequest/XMLHttpRequestOverride.ts#L254-L255

I think everything else could be left as-is, the order looks correct:

1. Headers received.
2. ReadyStateChange to propagate the received headers.
3. progress.
4. load.
5. loadend.

If you have a chance, please open a pull request with the changes so we could review it and make this improvement happen! Thank you.

from interceptors.

Hi there!

I've been doing a little bit of research on this because I could use a bit of context myself and I really would like to understand what this does behind the scenes.
As stated by @marcosvega91 on #75, loadstart should be triggered prior to progress?
Seems like the order would imply that the triggerReadyStateChange event needs to happen first, followed by the loadstart event, and then by the progress event.

this.triggerReadyStateChange()

// Initiates the request
this.trigger('loadstart')

// ...
if (mockedResponse.body && this.response) {
  // ...
  this.trigger('progress', {
    loaded: bodyBuffer.length,
    total: bodyBuffer.length,
  })
}

this.readyState = this.DONE

I believe that (and please correct me if I'm wrong) both error and abort are being handled depending on whether there's an exception in middlewareException? Would this mean (according to the order) that abort needs to come prior to error?

this.abort()
this.trigger('error')

Which only leaves

this.trigger('load')
this.trigger('loadend')

Left in the sequence, and only leaves me wondering if the timeout event should be implemented at all given that is a mocked response? I see that it happens if the response is not mocked and proceeds to fetch the actual URL.

Thanks for your attention and would love to contribute to this awesome library! 🙌

from interceptors.

Awesome, thanks for clearing it out! Opened #102 🙌

from interceptors.