navigator.getGamepads() should return a Promise

[cvan]

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 a Promise resolving an array of Gamepad objects (instead of returning the array, per the current spec + implementations).

[luser]

I don't know how we could do this without breaking all the existing users of the API.

[danwdart]

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?

[daoshengmu]

It might needn't. In FF, we just return the gamepads that already emit its first event, so it is not async behavior.

[GrosSacASac]

you can always make a Promise on top off the events gamepadconnected

[cvan]

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?

[dgchrt]

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?

[marcoscaceres]

Going ahead and closing this, as it would break things.... The events at #152 should make the API better.