Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow users to respond to other ajax event states. #1725

Closed
mgol opened this issue Oct 20, 2014 · 13 comments

Comments

Projects
None yet
3 participants
@mgol
Copy link
Member

commented Oct 20, 2014

Originally reported by hungerandthirst@… at: http://bugs.jquery.com/ticket/9883

The jQuery docs explicitly state that "No onreadystatechange mechanism is provided, however, since success, error, complete and statusCode cover all conceivable requirements."

Frankly I think that's limiting users unnecessarily. What if I want to respond to something when I get headers back? What if I want to know when I start receiving content back from the server?

An excellent example of this is using jQuery for bandwidth testing. Without a way to detect when I initially receive content back from the server (not just beforeSend), I will also include any delay spent waiting for the server to respond.

I've added support for the RECEIVE_HEADER and LOADING event as per the XMLHttpRequest specs in  this pull request.

I would also like to see support for onreadystatechange as well since those are valuable states that we are only limiting ourselves and losing value by not tracking.

Issue reported for jQuery git

@mgol

This comment has been minimized.

Copy link
Member Author

commented Oct 20, 2014

Comment author: jaubourg

First of all, onreadystatechange and xhr events support was removed from the original rewrite because:

  • size was beginning to be a real, blocking, issue
  • they're not used as much as one may think (there are use cases for them, but they do not represent a need widespread enough to justify the quite substantial bump in size, especially if you already have success, error and complete callbacks).

The jqXHR object doesn't strive to implement the whole xhr API. It's as complete an xhr-compatible wrapper as it makes sense relatively to the diversity of transports under the hood.

Your bandwidth detection example is clearly not a typical use-case for a web app (and that's putting it mildly). Beside, if you wanted to have full control over the xhr, you can still use jQuery.ajaxSettings.xhr() to create a native xhr (because, in the end, given the level of control you require, you don't need ajax to intervene on top of the native xhr -- by setting headers automagically without your knowledge for instance).

As to the patch itself, what I really don't like about it, is that you create specific options that only make sense for the xhr transport.

If you really want those right now and insist on using ajax for low-level control over the xhr, you can easily copy the code of  https://github.com/jquery/jquery/blob/master/src/ajax/xhr.js, apply your patch and change line 52 into:

jQuery.ajaxTransport( "+*", function( s ) {

Drop the file as is in your application: it'll override the default xhr transport and you'll be able to do whatever you need to.

That being said, I know we need some progress notification system but, guess what? We'll have progress callbacks on Deferreds/Promises in 1.7 which would be a perfect fit for this kind of things :)

Given Deferreds' progress is transport agnostic, each transport will be able to provide its own progress notification protocol.

I leave this as opened for now, given that I'd love to see something to notify readyState changes using Deferreds' progress make it as soon as 1.7. But, since this wasn't brought when proposals for new features in 1.7 were in order, I doubt we'd see this before 1.8. On the other hand, the addition would be pretty neutral since progress callbacks didn't exist earlier (no code breakage since existing behaviour stays unchanged).

Anyway:

  • yes, we need some kind of a progress notification system for transports,
  • no, adding options specific to a given transport is not an acceptable approach,
  • let's use Deferreds' progress introduced in 1.7 for this so that all transports can notify their own "events".

I'll try and take this conversation forward in the next jQuery meeting.

@mgol

This comment has been minimized.

Copy link
Member Author

commented Oct 20, 2014

Comment author: jaubourg

#9324 is a duplicate of this ticket.

@mgol

This comment has been minimized.

Copy link
Member Author

commented Oct 20, 2014

Comment author: jaubourg

#10365 is a duplicate of this ticket.

@mgol

This comment has been minimized.

Copy link
Member Author

commented Oct 20, 2014

Comment author: dmethvin

Bulk change from enhancement to feature.

@mgol

This comment has been minimized.

Copy link
Member Author

commented Oct 20, 2014

Comment author: dmethvin

Do progress callbacks make this easy now?

@mgol

This comment has been minimized.

Copy link
Member Author

commented Oct 20, 2014

Comment author: hungerandthirst@…

Don't know off the top. I will need to investigate and get back to you. Have not had a chance to look into the new callbacks yet.

@mgol

This comment has been minimized.

Copy link
Member Author

commented Oct 20, 2014

Comment author: mikesherov

+0, I'm not informed enough to choose.

@mgol

This comment has been minimized.

Copy link
Member Author

commented Oct 20, 2014

Comment author: gnarf

+1, I think we should at least look at using .notify to send something about this state change - Measure the size, and then decide

@mgol

This comment has been minimized.

Copy link
Member Author

commented Oct 20, 2014

Comment author: jaubourg

FYI, preliminary study indicates adding a minimal implementation of a progress callback which the xhr transport would call at each readystate with the native xhr instance as sole parameter (so that it can be inspected and used) is in the vicinity of 30bytes min/gzipped. Any attempt to make it more secure (not expose the native xhr directly) or more useful (call the progress handlers with meaningful parameters) can only make it much bigger and is actually the desirable approach.

I'm quite torn here, because I know how useful it would be yet I feel like it will be too much weight at this point. Since I know the xhr transport will be extremely simplified for 2.x, I'd like to postpone this.

@mgol

This comment has been minimized.

Copy link
Member Author

commented Oct 20, 2014

Comment author: dmethvin

I'm fine with moving this to a later date. We'll have plenty of other things to keep us busy in the next couple of months. :)

@mgol

This comment has been minimized.

Copy link
Member Author

commented Oct 20, 2014

Comment author: anonymous

Replying to dmethvin: Just do it. If anything adding this support will introduce a lot of people to progress(), which I have always thought was such a clever part of $.Deferred.

@mgol

This comment has been minimized.

Copy link
Member Author

commented Oct 20, 2014

@dmethvin

This comment has been minimized.

Copy link
Member

commented Dec 5, 2014

See comments in gh-1541

@dmethvin dmethvin closed this Dec 5, 2014

@lock lock bot locked as resolved and limited conversation to collaborators Jun 20, 2018

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
You can’t perform that action at this time.