You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I've come across a bit of an edge-case, and I was hoping I could get a bit more insight into the decision for placing the xr event bindings before the opts event bindings?
The problem that I've encountered is that when a timeout occurs it is practically indistinguishable from a CORS error. The xhr object that's being passed back has virtually nothing that identifies which of the two scenarios caused the request to be rejected. Furthermore, the binding xr makes to the timeout event doesn't provide anything alongside the xhr object in the rejection.
I have attempted to bind my own listener using events in the args to the timeout event, however that callback is executed after the promise is rejected. Thus, if I have a catch afterwards, it executes before I have the opportunity to modify a flag variable to distinguish a timeout event from a CORS issue.
For example:
xr.get('//10.0.0.2',null,{timeout: 4000,// This only makes a difference with my PR, otherwise just wait for natural timeoutevents: {timeout: ()=>console.log('timeout')}}).catch(o=>console.log('error'))
I get:
error
timeout
Ideally, I'd like for my timeout binding to be fired before the promise is rejected or resolved. Especially since the xhr object is passed to the bound function, and allows me to tweak it so that I have a better idea of what when wrong when I eventually catch the failed request.
Is there a reason the optional bindings are executed after the promise is rejected/resolved? Or could the code be tweaked so that the optional bindings are executed first?
The text was updated successfully, but these errors were encountered:
I've come across a bit of an edge-case, and I was hoping I could get a bit more insight into the decision for placing the
xr
event bindings before theopts
event bindings?The problem that I've encountered is that when a timeout occurs it is practically indistinguishable from a CORS error. The
xhr
object that's being passed back has virtually nothing that identifies which of the two scenarios caused the request to be rejected. Furthermore, the bindingxr
makes to thetimeout
event doesn't provide anything alongside thexhr
object in the rejection.I have attempted to bind my own listener using
events
in theargs
to the timeout event, however that callback is executed after the promise is rejected. Thus, if I have a catch afterwards, it executes before I have the opportunity to modify a flag variable to distinguish a timeout event from a CORS issue.For example:
I get:
Ideally, I'd like for my
timeout
binding to be fired before the promise isrejected
orresolved
. Especially since thexhr
object is passed to the bound function, and allows me to tweak it so that I have a better idea of what when wrong when I eventuallycatch
the failed request.Is there a reason the optional bindings are executed after the promise is rejected/resolved? Or could the code be tweaked so that the optional bindings are executed first?
The text was updated successfully, but these errors were encountered: