Skip to content

Replace "asynchronous completions" with a callback algorithm#8264

Merged
domenic merged 17 commits into
whatwg:mainfrom
nicolo-ribaudo:remove-async-completions
Sep 28, 2022
Merged

Replace "asynchronous completions" with a callback algorithm#8264
domenic merged 17 commits into
whatwg:mainfrom
nicolo-ribaudo:remove-async-completions

Conversation

@nicolo-ribaudo

@nicolo-ribaudo nicolo-ribaudo commented Sep 5, 2022

Copy link
Copy Markdown
Member

This fixes the first bullet point of #7996.

  • fetch a classic script
  • fetch a classic worker script
  • fetch an external module script graph
  • fetch an import() module script graph
  • fetch a modulepreload module script graph
  • fetch an inline module script graph
  • fetch a module worker script graph
  • fetch a worklet script graph
  • fetch a worklet/module worker script graph
  • fetch the descendants of and link a module script
  • fetch the descendants of a module script *
  • internal module script graph fetching procedure *
  • fetch a single module script
  • "asynchronously complete" in the various perform the fetch steps
    • I made it receive a named processCustomFetchResponse parameter, so that it's invoked with the same wording as fetch's processResponseConsumeBody.

/links.html ( diff )
/scripting.html ( diff )
/webappapis.html ( diff )
/workers.html ( diff )
/worklets.html ( diff )

@nicolo-ribaudo nicolo-ribaudo marked this pull request as draft September 5, 2022 16:51

@domenic domenic left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Really great work; much appreciated!

Comment thread source Outdated
@domenic domenic added clarification Standard could be clearer topic: script labels Sep 6, 2022
@nicolo-ribaudo nicolo-ribaudo marked this pull request as ready for review September 13, 2022 15:07
@nicolo-ribaudo

nicolo-ribaudo commented Sep 13, 2022

Copy link
Copy Markdown
Member Author

@domenic This should be ready!

EDIT: Please consider the participation agreement as not signed until whatwg/sg#197 is resolved (and anyway, thanks for verifying me :) )

Comment thread source

@domenic domenic left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks great, with a few nits! Impressive work on refactoring the worklet stuff and the descendants!

Comment thread source
data-x="fetching-scripts-processCustomFetchResponse">processCustomFetchResponse</i> given <span
data-x="concept-response">response</span> <var>response</var>.</p>

<p>Otherwise, <span data-x="concept-fetch">fetch</span> <var>request</var>. Return from this

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm, I guess we are using processResponseConsumeBody here, but that is not really correct since step 10 later tries to mess with the body, and it mismatches processCustomFetchResponse which takes a response, not a body...

I guess since this is a preexisting problem, we can defer it until we fix the third bullet point from #7996. It just got a little easier to see the problem now, since processCustomFetchResponse and processResponseConsumeBody have a clear signature mismatch.

Comment thread source
@@ -92878,9 +92900,10 @@ document.querySelector("button").addEventListener("click", bound);
<p>If the caller specified custom steps to <span data-x="fetching-scripts-perform-fetch">perform
the fetch</span>, perform them on <var>request</var>, with the <var
data-x="fetching-scripts-is-top-level">is top-level</var> flag set. Return from this algorithm,

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think as part of #7996 we should eventually stop using the "Return from this algorithm and run the remaining steps" style, and just use explicit callbacks. Especially since we have the same callback being passed to two different algorithms.

I think your "onComplete as defined below" style is pretty good for this.

Comment thread source Outdated
Comment thread source Outdated
Comment thread source Outdated
Comment thread source Outdated
Comment thread source Outdated
Comment thread source Outdated
@nicolo-ribaudo

Copy link
Copy Markdown
Member Author

Thanks for the review! I added the two more general comments to #7996 and I'll handle them in separate PRs, to keep this one about async completions.

@domenic domenic left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM with one suggested change that I'd like your confirmation on, otherwise I would just push it and merge myself.

Comment thread source Outdated
@domenic domenic merged commit 1fcb55e into whatwg:main Sep 28, 2022
@nicolo-ribaudo nicolo-ribaudo deleted the remove-async-completions branch September 28, 2022 05:53
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

clarification Standard could be clearer topic: script

Development

Successfully merging this pull request may close these issues.

3 participants