-
Notifications
You must be signed in to change notification settings - Fork 2.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add types to parameters of script fetching algorithms #9530
Add types to parameters of script fetching algorithms #9530
Conversation
2c089be
to
d1c452c
Compare
d1c452c
to
b6dd0a4
Compare
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This was referring to a flag that didn't actually exist anymore.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you so much for this work!
<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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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).
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 )