You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, HTML references the custom "perform the fetch" steps in a way that makes it a little difficult to understand how those steps influence overall script retrieval.
The algorithm delegates retrieval of the rest of the graph to fetch the descendants of and link a module script, but it does not reference the optional "perform the fetch" steps. This suggests that the steps are not relevant for the retrieval of the descendants. Similarly, the steps are not referenced in the corresponding call to fetch the descendants of a module script. Only by reviewing the steps of that algorithm (twice removed from "fetch a module worker script") can one learn that retrieval of the descendants may be affected by the custom "perform the fetch" steps:
For each url in urls, perform the internal module script graph fetching procedure given url, fetch client settings object, destination, options, module script's settings object, visited set, and module script's base URL. If the caller of this algorithm specified custom perform the fetch steps, pass those along while performing the internal module script graph fetching procedure.
This wording is somewhat unclear, though: this algorithm currently has two call sites in HTML, and neither of them specify custom "perform the fetch" steps. This makes me think the term "caller" may encompass the entire "call stack" as it were. However, it's also possible that the condition is truly limited to direct callers and simply describing call sites that exist outside of HTML.
If the former is true, then this would be greatly clarified if the intervening algorithms accepted the steps as input and passed them along explicitly.
@domenic This feels similar to work you've been doing to improve coherence. Apologies if it's already on your radar; my search didn't turn anything up.
The text was updated successfully, but these errors were encountered:
Currently, HTML references the custom "perform the fetch" steps in a way that makes it a little difficult to understand how those steps influence overall script retrieval.
Fetch a module worker script graph directly invokes fetch a single module script to retrieve the entry point to a script graph. When it does this, it explicitly forwards the "perform the fetch" steps that callers can optionally provide.
The algorithm delegates retrieval of the rest of the graph to fetch the descendants of and link a module script, but it does not reference the optional "perform the fetch" steps. This suggests that the steps are not relevant for the retrieval of the descendants. Similarly, the steps are not referenced in the corresponding call to fetch the descendants of a module script. Only by reviewing the steps of that algorithm (twice removed from "fetch a module worker script") can one learn that retrieval of the descendants may be affected by the custom "perform the fetch" steps:
This wording is somewhat unclear, though: this algorithm currently has two call sites in HTML, and neither of them specify custom "perform the fetch" steps. This makes me think the term "caller" may encompass the entire "call stack" as it were. However, it's also possible that the condition is truly limited to direct callers and simply describing call sites that exist outside of HTML.
If the former is true, then this would be greatly clarified if the intervening algorithms accepted the steps as input and passed them along explicitly.
@domenic This feels similar to work you've been doing to improve coherence. Apologies if it's already on your radar; my search didn't turn anything up.
The text was updated successfully, but these errors were encountered: