v152 · gamepad button type
Past the end of the map
An application that wants to use a trackpad or a back paddle has exactly one clue: the device id string. This page builds the lookup table that clue forces you to write, runs it against a set of real id strings, and counts how often it is wrong.
The lookup table, as an application would write it
| device id | matched rule | button 17 | button 18 |
|---|
The device strings above are examples of the shape these take, not a database — the same physical controller reports differently on Windows, macOS and Linux, and differently again between browsers. That is the point: a substring match against free text is the only tool available, and it fails on any device whose string nobody has seen.
Against a controller you actually have
If a controller is connected, its real id string is run through the same table. That is the honest test of a lookup table: not whether it handles the devices it was written for, but whether it handles yours.
What a type replaces
| question | with a lookup table | with button.type |
|---|
The code, both ways
// Today.
const table = buildTableFromIdStrings(); // maintained by hand, forever
const rule = table.find((entry) => gamepad.id.includes(entry.match));
const name = rule?.buttons[index] ?? `button ${index}`;
// With the addition.
const name = gamepad.buttons[index].type ?? `button ${index}`;The fallback does not go away — a button the browser has no name for still needs one from somewhere. What goes away is the table, and with it the class of bug where a controller released after your last deploy is silently mis-labelled rather than unlabelled.