[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 [§ 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