just curious as to what the rationale was for changing the readyList array from a public property to a private variable with the 1.4 release. i realize that direct manipulation of the readyList could have some unexpected results, especially in team-based dev environments. with that being said, however, there are cases where direct manipulation of the readyList can be very helpful. consider the following:
i work for a company with a huge site that uses third-party tracking/analytics software. the particular library we are using is filled with blocking-behavior. as we cannot remove/refactor the code at this time, prior to the 1.4 release i was able to replace a static script node, i.e:
with something much more elegant, and without the blocking (as the page is already loaded)
// Make sure the tracking code is added before any other dom-ready blocks run
arguably, this can still be achieved via:
but that approach has some significant drawbacks, like the fact that each independent author (page-specific code, widgets, plugins, etc) needs to implement a check for the tracking software and load it if necessary. i was using this approach on several pages, which allowed adding/removing/refactoring the various blocks of js on each page a breeze, as the individual blocks could assume that the software was always available.
can anyone shed some light on why this was done? i'm hoping there is a better answer than "well, that array is used internally so should not be publicly accessible" ... i agree with that sentiment but it is also a fairly drastic change to make. even if the ability to manipulate the readyList was never documented or intended, it was available nonetheless, which leads me to claim regression.
It's due to the fact that ready is (and should be) an event - the fact that some of the internals were exposed was a mistake (one that we're working to rectify). As you mentioned it was undocumented and its exposure was unintended.
In your case manipulation of readyList is absolutely not needed (and would likely break if you tried to load your script dynamically). I recommend that you just call getScript directly.
thanks for your reply! although that's not the answer i was hoping for, it is the one that i expected and i understand... the use case above was probably a little contrived, but i think there are cases where direct manipulation would be beneficial, for example when multiple plugins are reliant on each other.
at any rate, thanks for following up and for all the hard work.
Leave a comment on jeresig's reply
Change topic type
Link this topic
Provide the permalink of a topic that is related to this topic