Bug Tracker

Opened 10 years ago

Closed 10 years ago

#6185 closed enhancement (wontfix)

ready( fn ) should not be synchronous

Reported by: hallettj Owned by:
Priority: Milestone: 1.4.3
Component: event Version: 1.4.2
Keywords: ready, synchronous Cc:
Blocked by: Blocking:

Description

I am sure this has been discussed before; but I was not able to find such a discussion.

I noticed that if jQuery.isReady is true when ready( fn ) is called then the given callback is called synchronously. This bit me when I set up a mildly complicated class hierarchy in which I set one class to trigger an event in a ready( fn ) callback on instance initialization and set another class to listen for the same event. This all takes place in a single synchronous chunk of JavaScript where the initialization of one instance creates a new instance of the other.

Because that event registration takes places after the other class is initialized my code ends up missing the event. If ready( fn ) were called asynchronously in every case this would not be a problem.

I will cite the principle of least surprise to make the argument that ready( fn ) should behave as consistently as possible - that is it should invoke its callback asynchronously under all circumstances. Because it does not I 1) was surprised and 2) had to wrap a setTimout() around my event-triggering callback to handle the special case where an instance is initialized after the document is ready.

My proposed change is attached as a patch.

Attachments (1)

0001-ready-fn-should-not-run-synchronously.patch (1.4 KB) - added by hallettj 10 years ago.
patch that wraps invocation of a callback with setTimeout()

Download all attachments as: .zip

Change History (2)

Changed 10 years ago by hallettj

patch that wraps invocation of a callback with setTimeout()

comment:1 Changed 10 years ago by john

Resolution: wontfix
Status: newclosed

While I absolutely do appreciate the patch and test case I'm not convinced by the particular need for this. Considering that the DOM is already ready it would actually be very surprising to have your code execution be delayed by an additional 15ms or so (depending upon the browser). I'm also hesitant to make the change since it's likely that there are already users depending upon the existing behavior (executing synchronously after the DOM is ready).

This would probably be a good topic to bring up in discussion on the jQuery forum.

Note: See TracTickets for help on using tickets.