W3C home > Mailing lists > Public > public-device-apis-log@w3.org > October 2019

[wake-lock] Consider not defining a custom WakeLockEvent (#238)

From: Reilly Grant via GitHub <sysbot+gh@w3.org>
Date: Wed, 16 Oct 2019 20:38:25 +0000
To: public-device-apis-log@w3.org
Message-ID: <issues.opened-508086040-1571258304-sysbot+gh@w3.org>
reillyeon has just created a new issue for https://github.com/w3c/wake-lock:

== Consider not defining a custom WakeLockEvent ==
Reading the TAG design principles I noticed [&sect; 3.7. State and Event subclasses](https://w3ctag.github.io/design-principles/#state-and-subclassing) which recommends against creating custom `Event` subclasses and instead capturing state in the `target` parameter.

Example code with current API,

```javascript
let lock = await navigator.wakeLock.request({ type: "script" });
lock.addEventListener('release', e => {
  console.log(`${e.lock.type} wake lock has been released`);
});
```

Since the event is already fired on `lock` the `lock` attribute on the event could be removed, resulting in this code,

```javascript
let lock = await navigator.wakeLock.request({ type: "script" });
lock.addEventListener('release', e => {
  console.log(`${e.target.type} wake lock has been released`);
});
```

Please view or discuss this issue at https://github.com/w3c/wake-lock/issues/238 using your GitHub account
Received on Wednesday, 16 October 2019 20:38:27 UTC

This archive was generated by hypermail 2.4.0 : Monday, 4 July 2022 12:47:57 UTC