Avoid global?

[slightlyoff]

It might make as much (or more) sense to view this at a promise-returning API; e.g.:

async function main() {
  // feature detection.
  if (!navigator.idle) {
    console.log("Idle detection is not available :(");
    return;
  }

  console.log("Idle detection is available! Go idle!");

  try {
    await detector = navigator.idle.request({ threshold: 60 });
    // maybe we can implicitly start here? Is there a good reason not to?
    detector.addEventListener('change', ({user, screen}) => { 
      console.log(`idle change: ${user}, ${screen}`);
    });
  } catch (e) {
    // deal with initialization errors.
    // permission denied, running outside of top-level frame, etc
  }
};

[domenic]

I prefer the current proposed API shape as opposed to the non-constructible navigator.idle object.

[samuelgoto]

i don't feel strongly either way.

just so that i can document the alternatives considered and their rationale, can you help me understand the trade-offs here? i understand polluting the global namespace, but what other factors should we have in mind? the precedence we piggy-backed on was the Generic Sensors API (per domenic's guidance), but I'm wondering if there are established guidance / recommendations / precedence that we could leverage here.

On Wed, Oct 30, 2019 at 10:28 AM Domenic Denicola notifications@github.com wrote:

I prefer the current proposed API shape as opposed to the non-constructible navigator.idle object.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/samuelgoto/idle-detection/issues/10?email_source=notifications&email_token=AAFJL2XCPXVAVNO3NGZO5G3QRG725A5CNFSM4JGA5Y6KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOECVCT2Y#issuecomment-548022763, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAFJL2QIHQ4EYPS6SFGUGDTQRG725ANCNFSM4JGA5Y6A .

-- f u cn rd ths u cn b a gd prgmr !

[domenic]

For me the important design principle is https://w3ctag.github.io/design-principles/#constructors

[reillyeon]

Can this issue be closed?

[reillyeon]

An advantage of an API like navigator.idle.query() is that we don't have a two-phase construction process where first the constructor is called and then start() is called. I've been considering adding an AbortSignal parameter so that the IdleDetector can be stopped but I'm uncertain if it should be a parameter to the constructor or start().

A query() method would match the pattern seen in the Permissions and Battery Status APIs.

[tomayac]

Have you considered a sentinel pattern as we have with Wake Lock?

[reillyeon]

@tomayac I think that is essentially the recommendation here. A method like navigator.idle.query() would return an IdleDetector which is already in the "started" state. IdleDetector is a little more than a sentinel since it provides state information.

[reillyeon]

Based on the design principle argument above I am going to close this issue. The differences between the various options seem cosmetic at best.