Should we pass parameters to the event listener and drop the per instance state?

[samuelgoto]

Right now, our API is such that you get the state out of the detector, and you listen for "change" events to observe changes.

let idleDetector = new IdleDetector({ threshold: 60 });
idleDetector.addEventListener('change', () => {
  // we get the state from the idle detector instance
  let {user, scree} = idleDetector.state;
  console.log(`idle change: ${user}, ${screen}`);
});
idleDetector.start();

We should probably drop the "state" property of IdleDetector and pass it on the event listener as a parameter, e.g.:

let idleDetector = new IdleDetector({threshold: 60});
idleDetector.addEventListener('change', ({user, screen}) => {
  // the state is passed as a parameter to the event listener.
  // idleDetector.state == undefined.
  console.log(`idle change: ${user}, ${screen}`);
});
idleDetector.start();

Not entirely consistent with the sensors API [1], but the "reading" in the sensors API doesn't seem like the best analogy either.

@reillyg, does that make sense? any other supporting precendence here?

[1] https://developer.mozilla.org/en-US/docs/Web/API/Accelerometer

[reillyeon]

I'm not aware of official guidance one way or another but other APIs like Web Bluetooth also follow the pattern of keeping the state on the object at which the event is fired rather than passing it as part of the event.

[reillyeon]

Having the current state on the object also matches things like the Battery Status API.

Can we close this issue?