W3C home > Mailing lists > Public > whatwg@whatwg.org > March 2014

Re: [whatwg] Promise-vending loaded() & ready() methods on various elements

From: Jake Archibald <jaffathecake@gmail.com>
Date: Fri, 14 Mar 2014 14:51:01 +0000
Message-ID: <CAJ5xic9A8SGtrMsd6Rmw=hFCz0kKLLccuV5Ev9wyw5USvkwK6A@mail.gmail.com>
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

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 17:00:17 UTC