Add types to parameters of script fetching algorithms#9530
Add types to parameters of script fetching algorithms#9530domenic merged 6 commits intowhatwg:mainfrom
Conversation
nicolo-ribaudo
force-pushed
the
script-fetching-algorithms-signatures
branch
from
2c089be to
d1c452c
Compare
nicolo-ribaudo
changed the title
nicolo-ribaudo
force-pushed
the
script-fetching-algorithms-signatures
branch
from
d1c452c to
b6dd0a4
Compare
nicolo-ribaudo
force-pushed
the
script-fetching-algorithms-signatures
branch
from
b6dd0a4 to
010758d
Compare
| data-x="">sharedworker</code>", or "<code data-x="">serviceworker</code>", and the <var>top-level | ||
| module fetch</var> flag is set, then set <var>request</var>'s <span | ||
| data-x="">sharedworker</code>", or "<code data-x="">serviceworker</code>", and | ||
| <var>isTopLevel</var> is true, then set <var>request</var>'s <span |
There was a problem hiding this comment.
This was referring to a flag that didn't actually exist anymore.
domenic
left a comment
domenic
left a comment
There was a problem hiding this comment.
Thank you so much for this work!
source
Outdated
| <span>environment settings object</span> <var>scriptSettings</var>, an <var>onComplete</var> | ||
| algorithm, and an optional <span data-x="fetching-scripts-perform-fetch">perform the fetch | ||
| hook</span> <var>performFetch</var>, run these steps. <var>onComplete</var> must be an algorithm | ||
| accepting null (on failure) or a <span>classic script</span> (on success).</p> |
There was a problem hiding this comment.
What do you think of renaming the ESO arguments to fetchClient and settingsObject? I'm not sure myself.
There was a problem hiding this comment.
The ESO in the various algorithms are used in different ways, so it would make sense to name them based on usage:
- as a request client -> fetchClient
- as a script's settings object -> settingsObject
However, in many algorithms (such as fetch a classic script and fetch a classic worker-imported script) it's used as both.
Additionally, some algorithms have a moduleMapSettings which also ends up being used passed as a settingsObject to algorithms that have nothing to do with the module map.
I'll push a commit given precedence to settingsObject, let me know what you think about it
There was a problem hiding this comment.
An alternative is to call it settingsObject when there is one, and outsideSettingsObject/insideSettingsObject when there is two (similar to https://html.spec.whatwg.org/#worker-processing-model).
2 participants
This PR adds types to all the parameters of script fetching algorithms, and converts all their variables to camelCase instead of using spaces.
Fixes #7996
/webappapis.html ( diff )