richtr/NoSleep.js

Wake Lock API will superscede this library (hopefully soon)

Closed this issue ยท 6 comments

Documentation Is:

  • Missing
  • Needed
  • Confusing
  • Not Sure?

Please Explain in Detail...

Chrome is testing the new Wake Lock API: https://developers.google.com/web/updates/2019/12/nic79#wake-lock

This feature will allow the user to properly request to keep the device from sleeping.

Once this is released, we will be able to stop using NoSleep (unless backwards compatibility is required).

Your Proposal for Changes

Update the docs to tell users to use the Wake Lock API when it's ready.

The Screen Wake Lock API indeed might supersede this library in the longterm. On the Chrome team, since this API exists in Chromium browsers, we plan on actually rendering the library's underlying (genius) hack useless (see https://crbug.com/1086776 for details).

The proposed flow would be:

if ('wakeLock' in navigator) {
  // Use the native API:
  // https://web.dev/wakelock/#get-wake-lock
} else {
  // Use NoSleep.js:
  // https://github.com/richtr/NoSleep.js#usage
  // (Ideally dynamically load the library on-demand.)
}

Thanks for the heads up and I agree the Wake Lock API should supersede this library. We have an existing PR to detect for the Wake Lock API and only fallback to the rest of the code if that API is not detected.

I plan to rewrite this PR based on the latest Wake Lock API changes. The previous PR is out-of-date and based on an old version of the Wake Lock API.

๐Ÿ‘ This also sounds like a great plan. Maybe consider lazy-loading only the relevant code paths.

Maybe consider lazy-loading only the relevant code paths.

This seems quite difficult to pull off unless we could rely 100% on access to a CDN for that (and presumably, that lazy loading approach would fail in offline modes). It might be something to consider in the future.

In browser-nativefs, I use a dynamic import().

Fixed by #95 and now released as v0.11.0 ๐Ÿ‘