Re: [w3ctag/design-reviews] Element.isVisible review (Issue #734)

> We had some trouble following this, how does making the API async complicate this use case?

Consider something like
```js
function getSize(e) {
  if (e.checkVisibility())
    return e.getBoundingClientRect();
  else
    return new DOMRect();
}

function foo() {
  /* gather some information about the current DOM state */
  ...
  let size = getSize(e);
  ...
  /* do something with the information and size */
  ...
}
```

Here, `getSize` function has been updated to use `checkVisibility`; it used to (for sake of argument) just return `getBoundingClientRect`, which used to cause unnecessary rendering work. This now costs _some_ necessary rendering work but no layout is needed for c-v hidden cases.

This is a correct update that affects one function because of synchronous nature of the API.

Now in order to update this same code but to use an asynchronous function, we have two options: `await` and `promise.then`. With await, this looks something like the following

```js
async function getSize() {
  let is_visible = await e.checkVisibility();
  if (is_visible)
    return e.getBoundingClientRect();
  else
    return new DOMRect();
}

async function foo() {
  /* gather some information about the current DOM state */
  ...
  let size = await getSize();
  ...
  /* do something with the information and size,
     however the information we got about the current DOM state may no longer be correct,
     because getSize did asynchronous work which could have resulted in rAF callbacks, for example,
     modifying DOM state. */
  ...
}
```

Here the information we gathered may be out of date, and we need to further restructure the code, if possible, to still be correct. We also need to mark `foo` as async, which propagates further up the stack

The promise.then pattern definitely needs more refactoring here on top of getting new state.

Now, I'm not arguing that any of this is impossible to do. My only concern is that I don't see a compelling reason to force this complexity and async considerations on the developer when the synchronous version of the API seems to have no downsides, other than ensuring style is up to date (which is something that getBoundingClientRect would have done anyway)

> This applies to any async API, doesn’t it?

Yes. I was highlighting that (IMHO) it seems unnecessary to add this requirement for this particular API.

FWIW, I am be missing some aspect that the asynchronous version provides, but if my understanding is correct, it seems like the synchronous version is more flexible here

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/734#issuecomment-1289360337

You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/734/1289360337@github.com>