Skip to main content

Bug Tracker

Side navigation

#9883 closed feature (migrated)

Opened July 21, 2011 05:12PM UTC

Closed October 20, 2014 11:07PM UTC

Allow users to respond to other ajax event states.

Reported by: hungerandthirst@gmail.com Owned by: jaubourg
Priority: low Milestone: None
Component: ajax Version: git
Keywords: 1.9-discuss Cc:
Blocked by: Blocking:
Description

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.

Attachments (0)
Change History (15)

Changed July 21, 2011 11:25PM UTC by jaubourg comment:1

component: unfiledajax
milestone: None1.next
owner: → jaubourg
priority: undecidedlow
status: newassigned

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.

Changed July 23, 2011 01:32AM UTC by jaubourg comment:2

#9324 is a duplicate of this ticket.

Changed May 06, 2012 02:03AM UTC by jaubourg comment:3

#10365 is a duplicate of this ticket.

Changed September 09, 2012 01:10AM UTC by dmethvin comment:4

type: enhancementfeature

Bulk change from enhancement to feature.

Changed September 17, 2012 05:39PM UTC by gibson042 comment:5

keywords: → 1.9-discuss

Changed September 24, 2012 04:56PM UTC by dmethvin comment:6

Do progress callbacks make this easy now?

Changed September 24, 2012 06:45PM UTC by hungerandthirst@gmail.com comment:7

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.

Changed October 14, 2012 10:19PM UTC by mikesherov comment:8

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

Changed October 29, 2012 04:55PM UTC by gnarf comment:9

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

Changed October 29, 2012 04:58PM UTC by mikesherov comment:10

milestone: 1.next1.9

Changed December 07, 2012 02:50PM UTC by jaubourg comment:11

_comment0: 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 disirable 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.1354891895840208

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.

Changed December 07, 2012 04:31PM UTC by dmethvin comment:12

milestone: 1.9None

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. :)

Changed February 28, 2014 05:55PM UTC by anonymous comment:13

Replying to [comment:12 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.

Changed March 16, 2014 02:09PM UTC by dmethvin comment:14

Changed October 20, 2014 11:07PM UTC by m_gol comment:15

resolution: → migrated
status: assignedclosed