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

Ensuring ordering on conditional use of promises: Example is fundamentally flawed #33581

Open
BrianJDrake opened this issue May 13, 2024 · 0 comments
Labels
Content:WebAPI Web API docs needs triage Triage needed by staff and/or partners. Automatically applied when an issue is opened.

Comments

@BrianJDrake
Copy link

MDN URL

https://developer.mozilla.org/en-US/docs/Web/API/HTML_DOM_API/Microtask_guide

What specific section or headline is this issue about?

Ensuring ordering on conditional use of promises

What information was incorrect, unhelpful, or incomplete?

That section contains this example:

customElement.prototype.getData = (url) => {
  if (this.cache[url]) {
    this.data = this.cache[url];
    this.dispatchEvent(new Event("load"));
  } else {
    fetch(url)
      .then((result) => result.arrayBuffer())
      .then((data) => {
        this.cache[url] = data;
        this.data = data;
        this.dispatchEvent(new Event("load"));
      });
  }
};

This example seems to be fundamentally flawed for two reasons:

  1. The else clause is asynchronous, but the getData() method has a signature implying it is synchronous.
  2. It uses this in an arrow function.

But item 1 above is the real problem. The section continues with another example:

element.addEventListener("load", () => console.log("Loaded data"));
console.log("Fetching data…");
element.getData();
console.log("Data fetched");

The section points out that this code has inconsistent behavior, since the getData() method's if clause, unlike the else clause, is synchronous. But, again, the problem is that getData() is treated as synchronous when it is actually asynchronous!

The section then points out a supposed fix: instead of having just one clause of getData() contradict its signature by being asynchronous, make both clauses contradict its signature by being asynchronous! This makes no sense; all it does is make the code even harder to reason about, and it does nothing to explain how microtasks have a legitimate use.

What did you expect to see?

I expected to see an explanation of:

  1. Why it is necessary to manually ensure correct ordering on conditional use of promises.
  2. In particular, why it might be necessary to explicitly introduce asynchronicity into an execution path that would ordinarily be entirely synchronous.
  3. Why microtasks are the right way to do the things mentioned above, and therefore why microtasks have legitimate uses.

Do you have any supporting links, references, or citations?

No response

Do you have anything more you want to share?

No response

MDN metadata

Page report details
@BrianJDrake BrianJDrake added the needs triage Triage needed by staff and/or partners. Automatically applied when an issue is opened. label May 13, 2024
@github-actions github-actions bot added the Content:WebAPI Web API docs label May 13, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Content:WebAPI Web API docs needs triage Triage needed by staff and/or partners. Automatically applied when an issue is opened.
Projects
None yet
Development

No branches or pull requests

1 participant