Re:Don't wait for "DOM ready" for your app to start
by shawndumas on Saturday June 09, 2012 @04:04PM
(#4089128)
That's a good idea.
I envisioned using it both for on-ready and for processes that might occur after page load. Sometimes widgets don't have callbacks, or for a long running template being shoved into the dom or some other such situation.
I could add a fourth (optional) boolean parameter -- stopOnReady; false ends on pageLoad, true on pageReady, and null stops on condition === true.
As to a long running check; 1.) the reason I use interval, as opposed to timeout, is that if the number of client events get heavy it will delay invoking the condition function [1]. 2.) a getElementById is native and trivial (in other words -- just don't do anything crazy in the condition function).
----
Re:Don't wait for "DOM ready" for your app to start
by shawndumas on Saturday June 09, 2012 @06:34PM
(#4089531)
I made the discussed changes here[1]. You can run them here[2]. Thanks again for your constructive input.
---
I have an improvement suggestion. If the client supplies their own condition, like in your example waiting for a specific element to be loaded, what about (optionally) disabling the check once onload happens?
As it is, a rogue condition check could run indefinitely.