Skip to content
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

Replace "asynchronous completions" with a callback algorithm #8264

Merged
merged 17 commits into from
Sep 28, 2022

Conversation

nicolo-ribaudo
Copy link
Contributor

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

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
Copy link
Member

@domenic domenic left a comment

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!

source Show resolved Hide resolved
@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
Copy link
Contributor Author

nicolo-ribaudo commented Sep 13, 2022

@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 :) )

Copy link
Member

@domenic domenic left a comment

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!

and run the remaining steps as part of the <span data-x="fetching-scripts-perform-fetch">perform
the fetch</span>'s <i
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
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.

@@ -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
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.

source Show resolved Hide resolved
source Show resolved Hide resolved
source Show resolved Hide resolved
source Show resolved Hide resolved
source Show resolved Hide resolved
source Show resolved Hide resolved
@nicolo-ribaudo
Copy link
Contributor 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.

Copy link
Member

@domenic domenic left a comment

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.

source Show resolved Hide resolved
@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