Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

handle error events on xkeys that can be emitted during the init process before the instance is exposed for listener registration #113

Merged
merged 3 commits into from
Dec 5, 2024
Merged

handle error events on xkeys that can be emitted during the init process before the instance is exposed for listener registration #113

Changes from 1 commit
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
913403b
handle error events on xkeys that can be emitted during the init proc…
loucadufault Dec 3, 2024
faa35ef
style: lint
loucadufault Dec 4, 2024
494f579
revise implementation to simplify promise executor
loucadufault Dec 4, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
33 changes: 24 additions & 9 deletions packages/webhid/src/methods.ts
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -69,13 +69,28 @@ export async function setupXkeysPanel(browserDevice: HIDDevice): Promise<XKeys>
})
})

// Wait for the device to initialize:
try {
await xkeys.init()

return xkeys
} catch (e) {
await deviceWrap.close()
throw e
}
let alreadyRejected = false
return new Promise((resolve, reject) => {
const xkeysStopgapErrorHandler = (e: unknown) => {
if (alreadyRejected) {
console.error(`Xkeys: Error emitted after setup already rejected:`, e)
return
}
deviceWrap.close()
.then(() => reject())
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Minor note: is there a reason the reject() has no argument here? Should we reject(e)?

Copy link
Contributor Author

@loucadufault loucadufault Dec 4, 2024 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is for the path where deviceWrap.close() promise resolves, where it should resolve to a void promise, but still I want to avoid forwarding whatever value it resolves to as the rejected value of the enclosing (returned) promise in case the API of that method changes.

.catch(reject)
.finally(() => (alreadyRejected = true))
Copy link
Contributor Author

@loucadufault loucadufault Dec 4, 2024 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

doing this in the finally (old implementation) was not semantically coherent since the flag only makes sense when the promise rejects, not when it resolves (same applies below). So changed this.

}
// Handle all error events until the instance is returned
xkeys.on('error', xkeysStopgapErrorHandler)
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we don't use once intentionally. Until we have resolved back the instance to the caller, we are responsible to keep catching errors that may be emitted.


// Wait for the device to initialize:
xkeys.init()
.then(() => {
resolve(xkeys)
xkeys.removeListener('error', xkeysStopgapErrorHandler)
})
.catch(reject)
.finally(() => (alreadyRejected = true))
})
}
Loading