- From: Jake Archibald <jaffathecake@gmail.com>
- Date: Fri, 14 Mar 2014 14:51:01 +0000
- To: Domenic Denicola <domenic@domenicdenicola.com>
- Cc: "whatwg@lists.whatwg.org" <whatwg@lists.whatwg.org>, Boris Zbarsky <bzbarsky@mit.edu>
This, along with Ilya's proposed <link rel="preload"> ( https://docs.google.com/a/google.com/document/d/1HeTVglnZHD_mGSaID1gUZPqLAa1lXWObV-Zkx6q_HF4/edit#heading=h.x6lyw2ttub69), and JavaScript modules ( https://github.com/dherman/web-modules/blob/master/module-tag/explainer.md) gives us everything we need for sane & versitile dependency loading. Problem: Initialising an app on document ready, but also waiting for a particular stylesheet to apply Solution: https://gist.github.com/jakearchibald/955e4f014a264b1f50c4 Problem: Initialising an app after a non-module script Solution: https://gist.github.com/jakearchibald/000ab94ad9fa5cfe62a8 Taking the more complex use-cases from http://lists.w3.org/Archives/Public/public-whatwg-archive/2013Aug/0277.html… [Use-case Q:] Want to avoid executing a social-media script until the user give some intent, although the script should be preloaded. Solution: https://gist.github.com/jakearchibald/dd25f0f2cf47bf2ab93e [Use-case S:] One plugin wants to execute "A.js" and "B.js" in order following an interaction. Another wants to load "A.js" then "C.js" & "D.js" in either order. "A.js" should only execute once. Scripts aren't written as modules and out of developer's control. Solution: https://gist.github.com/jakearchibald/120309d88a8bf025e92e [Use-case T:] Preload 2 scripts, execute one or the other on particular interactions Solution: Same as Q. [Use-case U:] "A.js", "B.js", "C.js" - load them in parallel, execute in order, only execute when all have preloaded. Solution: https://gist.github.com/jakearchibald/5898e3a4fce62579d75b [Use-case V:] As U, but don't need to wait for all before executing. Stop executing if any script fails to load. Solution: https://gist.github.com/jakearchibald/ea7583d50bf3b46395e0 [Use-case W:] As W, but break on execution errors Solution: https://gist.github.com/jakearchibald/1b12a0e5414a69d9350f [Use-case X:] Loading non-js dependencies Solution: Use XHR + preload for prescanner [Use-case Y:] Some libraries may need async initialization. Solution: These libs should provide a ready promise. [Use-case Z:] Wait on existence of particular element before executing script Solution: Either put the <script> that handles script loading after the element in question, or use mutation observers Cheers, Jake. On 12 March 2014 14:27, Jake Archibald <jaffathecake@gmail.com> wrote: > On 12 March 2014 14:17, Domenic Denicola <domenic@domenicdenicola.com>wrote: >> >> var img = document.createElement("img"); >> var promise1 = img.loaded(); >> img.src =" foo.png"; >> var promise2 = img.loaded(); >> >> // (1) will promise1 be immediately fulfilled, since img has >> "about:blank" or similar loaded already? >> // (2) or will promise1 and promise2 fulfill at the same time, since >> promise1 waits until a src appears? >> // (3) or will promise1 be rejected with AbortError, similar to Jake's >> previous case? >> // (4) or it could be rejected with an "InvalidStateError" saying you >> can't wait for the loading of a non-src'ed image. >> >> Here (1), (3), and (4) seem to encourage a consistent model of "always >> ask for loaded() promises after setting src, otherwise it won't work". It's >> (2) that's problematic as if that's the case then asking for loaded() >> promises before setting src sometimes works, but usually doesn't. >> > > This is a very good point, and I'd say (4). > > Lets say you didn't change the src: > > (1) Means the promise would reject with an EncodingError as it isn't a > valid image format > (2) Would remain unresolved > (3) N/A > (4) Reject with InvalidStateError > > The consistency makes me like (4) the most. >
Received on Friday, 14 March 2014 14:51:27 UTC