Side navigation
#9389 closed enhancement (wontfix)
Opened May 22, 2011 07:07PM UTC
Closed January 18, 2012 03:36AM UTC
Make holdReady() Work After DOM Ready
| Reported by: | johncrenshaw@priacta.com | Owned by: | |
|---|---|---|---|
| Priority: | low | Milestone: | None |
| Component: | event | Version: | 1.6.1 |
| Keywords: | Cc: | ||
| Blocked by: | Blocking: |
Description
Allow holdReady() to work AFTER the document has loaded.
This is a big deal when using script loaders + AJAX content. It turns out that the change is also trivial: just 5 lines all in one place. My 1.6 pull request ( https://github.com/jquery/jquery/pull/371 ) includes the whole change (just a few lines long) and the discussion on the pull request includes a good explanation of how and why this is useful ( https://github.com/jquery/jquery/pull/371#issuecomment-1104081 ).
the cliff notes version is that a good script loader is an ideal way to resolve some of the nasty issues surrounding AJAX, widgets, and code architecture on both the client and server side. HOWEVER, for this to work, the ready event needs to be able to be deferred after the AJAX response: otherwise all we have is an over-architected way of putting stuff in the header during the page load process.
The edit DOES change one documented behavior: currently the documentation says that holdReady() does nothing after the document has loaded. This is likely a pretty useless behavior, since any call to holdReady still OUGHT to be reciprocal, and the logical expectation in the code is normally that functions passed to $(document).ready() will not fire when there is a hold. Bottom line, it is highly improbable that this change will break anything that anyone is depending on.
Attachments (0)
Change History (11)
Changed May 24, 2011 01:07AM UTC by comment:1
| component: | unfiled → event |
|---|---|
| keywords: | → needsreview |
| priority: | undecided → low |
| status: | new → open |
Changed July 12, 2011 07:10PM UTC by comment:2
| type: | bug → enhancement |
|---|
Confirmed in triage.
Changed September 01, 2011 07:02PM UTC by comment:3
https://github.com/jquery/jquery/pull/371#issuecomment-1615039
I'll leave the ticket open for discussion during 1.8 feature voting; the closed PR has very good discussion pro and con.
Changed October 07, 2011 02:55AM UTC by comment:4
| keywords: | needsreview → 1.8-discuss |
|---|
Changed December 10, 2011 07:34PM UTC by comment:5
-1, Script loaders should have their own conventions for this; redefining ready semantics just seems wrong.
Changed December 13, 2011 01:49PM UTC by comment:6
| description: | Allow holdReady() to work AFTER the document has loaded. \ \ This is a big deal when using script loaders + AJAX content. It turns out that the change is also trivial: just 5 lines all in one place. My 1.6 pull request ( https://github.com/jquery/jquery/pull/371 ) includes the whole change (just a few lines long) and the discussion on the pull request includes a good explanation of how and why this is useful ( https://github.com/jquery/jquery/pull/371#issuecomment-1104081 ). \ \ the cliff notes version is that a good script loader is an ideal way to resolve some of the nasty issues surrounding AJAX, widgets, and code architecture on both the client and server side. HOWEVER, for this to work, the ready event needs to be able to be deferred after the AJAX response: otherwise all we have is an over-architected way of putting stuff in the header during the page load process. \ \ The edit DOES change one documented behavior: currently the documentation says that holdReady() does nothing after the document has loaded. This is likely a pretty useless behavior, since any call to holdReady still OUGHT to be reciprocal, and the logical expectation in the code is normally that functions passed to $(document).ready() will not fire when there is a hold. Bottom line, it is highly improbable that this change will break anything that anyone is depending on. → Allow holdReady() to work AFTER the document has loaded.\ \ This is a big deal when using script loaders + AJAX content. It turns out that the change is also trivial: just 5 lines all in one place. My 1.6 pull request ( https://github.com/jquery/jquery/pull/371 ) includes the whole change (just a few lines long) and the discussion on the pull request includes a good explanation of how and why this is useful ( https://github.com/jquery/jquery/pull/371#issuecomment-1104081 ).\ \ the cliff notes version is that a good script loader is an ideal way to resolve some of the nasty issues surrounding AJAX, widgets, and code architecture on both the client and server side. HOWEVER, for this to work, the ready event needs to be able to be deferred after the AJAX response: otherwise all we have is an over-architected way of putting stuff in the header during the page load process.\ \ The edit DOES change one documented behavior: currently the documentation says that holdReady() does nothing after the document has loaded. This is likely a pretty useless behavior, since any call to holdReady still OUGHT to be reciprocal, and the logical expectation in the code is normally that functions passed to $(document).ready() will not fire when there is a hold. Bottom line, it is highly improbable that this change will break anything that anyone is depending on. |
|---|
+0
Changed December 13, 2011 02:59PM UTC by comment:7
| description: | Allow holdReady() to work AFTER the document has loaded.\ \ This is a big deal when using script loaders + AJAX content. It turns out that the change is also trivial: just 5 lines all in one place. My 1.6 pull request ( https://github.com/jquery/jquery/pull/371 ) includes the whole change (just a few lines long) and the discussion on the pull request includes a good explanation of how and why this is useful ( https://github.com/jquery/jquery/pull/371#issuecomment-1104081 ).\ \ the cliff notes version is that a good script loader is an ideal way to resolve some of the nasty issues surrounding AJAX, widgets, and code architecture on both the client and server side. HOWEVER, for this to work, the ready event needs to be able to be deferred after the AJAX response: otherwise all we have is an over-architected way of putting stuff in the header during the page load process.\ \ The edit DOES change one documented behavior: currently the documentation says that holdReady() does nothing after the document has loaded. This is likely a pretty useless behavior, since any call to holdReady still OUGHT to be reciprocal, and the logical expectation in the code is normally that functions passed to $(document).ready() will not fire when there is a hold. Bottom line, it is highly improbable that this change will break anything that anyone is depending on. → Allow holdReady() to work AFTER the document has loaded. \ \ This is a big deal when using script loaders + AJAX content. It turns out that the change is also trivial: just 5 lines all in one place. My 1.6 pull request ( https://github.com/jquery/jquery/pull/371 ) includes the whole change (just a few lines long) and the discussion on the pull request includes a good explanation of how and why this is useful ( https://github.com/jquery/jquery/pull/371#issuecomment-1104081 ). \ \ the cliff notes version is that a good script loader is an ideal way to resolve some of the nasty issues surrounding AJAX, widgets, and code architecture on both the client and server side. HOWEVER, for this to work, the ready event needs to be able to be deferred after the AJAX response: otherwise all we have is an over-architected way of putting stuff in the header during the page load process. \ \ The edit DOES change one documented behavior: currently the documentation says that holdReady() does nothing after the document has loaded. This is likely a pretty useless behavior, since any call to holdReady still OUGHT to be reciprocal, and the logical expectation in the code is normally that functions passed to $(document).ready() will not fire when there is a hold. Bottom line, it is highly improbable that this change will break anything that anyone is depending on. |
|---|
-1, Feature creep precedent
Changed December 13, 2011 04:02PM UTC by comment:8
| description: | Allow holdReady() to work AFTER the document has loaded. \ \ This is a big deal when using script loaders + AJAX content. It turns out that the change is also trivial: just 5 lines all in one place. My 1.6 pull request ( https://github.com/jquery/jquery/pull/371 ) includes the whole change (just a few lines long) and the discussion on the pull request includes a good explanation of how and why this is useful ( https://github.com/jquery/jquery/pull/371#issuecomment-1104081 ). \ \ the cliff notes version is that a good script loader is an ideal way to resolve some of the nasty issues surrounding AJAX, widgets, and code architecture on both the client and server side. HOWEVER, for this to work, the ready event needs to be able to be deferred after the AJAX response: otherwise all we have is an over-architected way of putting stuff in the header during the page load process. \ \ The edit DOES change one documented behavior: currently the documentation says that holdReady() does nothing after the document has loaded. This is likely a pretty useless behavior, since any call to holdReady still OUGHT to be reciprocal, and the logical expectation in the code is normally that functions passed to $(document).ready() will not fire when there is a hold. Bottom line, it is highly improbable that this change will break anything that anyone is depending on. → Allow holdReady() to work AFTER the document has loaded.\ \ This is a big deal when using script loaders + AJAX content. It turns out that the change is also trivial: just 5 lines all in one place. My 1.6 pull request ( https://github.com/jquery/jquery/pull/371 ) includes the whole change (just a few lines long) and the discussion on the pull request includes a good explanation of how and why this is useful ( https://github.com/jquery/jquery/pull/371#issuecomment-1104081 ).\ \ the cliff notes version is that a good script loader is an ideal way to resolve some of the nasty issues surrounding AJAX, widgets, and code architecture on both the client and server side. HOWEVER, for this to work, the ready event needs to be able to be deferred after the AJAX response: otherwise all we have is an over-architected way of putting stuff in the header during the page load process.\ \ The edit DOES change one documented behavior: currently the documentation says that holdReady() does nothing after the document has loaded. This is likely a pretty useless behavior, since any call to holdReady still OUGHT to be reciprocal, and the logical expectation in the code is normally that functions passed to $(document).ready() will not fire when there is a hold. Bottom line, it is highly improbable that this change will break anything that anyone is depending on. |
|---|
-1, You need another event for this. I won't repeat what I said in the pull request's comments.
Changed December 14, 2011 04:01PM UTC by comment:9
+0
Changed December 16, 2011 12:10AM UTC by comment:10
-1 IMHO scripts loaders and module loader should be used outside of jQuery. Not even in jQuery plugins. You should look at all of you javascript code as some kind of modules (even one big module), including jQuery.
The best practice is to load jQuery and other scripts on the bottom of the page and additional script loaders in the head (if some of the modules should be loaded based on some conditions even before loading and are crucial in the beginning) or if you don't have modules that needs to be loaded at the beginning you can use the loader in the bottom of the body as well.
Changed January 18, 2012 03:36AM UTC by comment:11
| description: | Allow holdReady() to work AFTER the document has loaded.\ \ This is a big deal when using script loaders + AJAX content. It turns out that the change is also trivial: just 5 lines all in one place. My 1.6 pull request ( https://github.com/jquery/jquery/pull/371 ) includes the whole change (just a few lines long) and the discussion on the pull request includes a good explanation of how and why this is useful ( https://github.com/jquery/jquery/pull/371#issuecomment-1104081 ).\ \ the cliff notes version is that a good script loader is an ideal way to resolve some of the nasty issues surrounding AJAX, widgets, and code architecture on both the client and server side. HOWEVER, for this to work, the ready event needs to be able to be deferred after the AJAX response: otherwise all we have is an over-architected way of putting stuff in the header during the page load process.\ \ The edit DOES change one documented behavior: currently the documentation says that holdReady() does nothing after the document has loaded. This is likely a pretty useless behavior, since any call to holdReady still OUGHT to be reciprocal, and the logical expectation in the code is normally that functions passed to $(document).ready() will not fire when there is a hold. Bottom line, it is highly improbable that this change will break anything that anyone is depending on. → Allow holdReady() to work AFTER the document has loaded. \ \ This is a big deal when using script loaders + AJAX content. It turns out that the change is also trivial: just 5 lines all in one place. My 1.6 pull request ( https://github.com/jquery/jquery/pull/371 ) includes the whole change (just a few lines long) and the discussion on the pull request includes a good explanation of how and why this is useful ( https://github.com/jquery/jquery/pull/371#issuecomment-1104081 ). \ \ the cliff notes version is that a good script loader is an ideal way to resolve some of the nasty issues surrounding AJAX, widgets, and code architecture on both the client and server side. HOWEVER, for this to work, the ready event needs to be able to be deferred after the AJAX response: otherwise all we have is an over-architected way of putting stuff in the header during the page load process. \ \ The edit DOES change one documented behavior: currently the documentation says that holdReady() does nothing after the document has loaded. This is likely a pretty useless behavior, since any call to holdReady still OUGHT to be reciprocal, and the logical expectation in the code is normally that functions passed to $(document).ready() will not fire when there is a hold. Bottom line, it is highly improbable that this change will break anything that anyone is depending on. |
|---|---|
| keywords: | 1.8-discuss |
| milestone: | 1.next → None |
| resolution: | → wontfix |
| status: | open → closed |
+1 As a script loader user, I would like this.