Closed cvan closed 3 years ago
I don't know how we could do this without breaking all the existing users of the API.
Many devs use a different method, like pGetGamepads or getGamepadsP... I suggest using a parameter? For instance getGamepads(true) will give you a promise and getGamepads(false) (default) won't?
It might needn't. In FF, we just return the gamepads that already emit its first event, so it is not async behavior.
you can always make a Promise on top off the events gamepadconnected
if we’re looking to make the Gamepad API safe for DOM contexts (which other issues cover), it probably makes sense to start thinking of creating a navigator.gamepads
namespace.
similar thing happened for navigator.getUserMedia
to navigator.mediaDevices.getUserMedia
and navigator.getVRDisplays
to navigator.vr.requestDevice
.
this might warrant its own issue, but this is all could be handled by namespacing the API, moving the DOM events to emit on an EventTarget
interface, and creating a Promise-based navigator.gamepads.get(…)
thoughts?
Currently navigator.getGamepads()
returns an Object
which already contains the up-to-the-minute status of gamepads. What would be the benefit of making this call asynchronous?
Going ahead and closing this, as it would break things.... The events at #152 should make the API better.
Perhaps this is a dupe of #17, and perhaps this should first be discussed on the mailing list, but I think
navigator.getGamepads()
should return aPromise
resolving an array ofGamepad
objects (instead of returning the array, per the current spec + implementations).