-
-
Notifications
You must be signed in to change notification settings - Fork 112
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.
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
feat(web): queued promise prioritizer / resynchronizer 🐵 #9453
Conversation
User Test ResultsTest specification and instructions User tests are not required Test Artifacts
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm although even with the initial explanation, I don't really understand the big picture gestures use case as the mechanical unit test of correctness doesn't really explain why the gestures design would need such a thing.
common/web/gesture-recognizer/src/engine/headless/queuedPromisePrioritizer.ts
Outdated
Show resolved
Hide resolved
common/web/gesture-recognizer/src/engine/headless/queuedPromisePrioritizer.ts
Outdated
Show resolved
Hide resolved
Took a bit of work, but I've been able to successfully remove this PR's changes from its descendants via reversion to the most direct descendant. As noted by #9407 (comment), the component added by this PR is no longer necessary, as a "deeper root" was identified and fixed. |
This was "fun".
Collects metadata on all near-synchronous calls to its lone public method, intended to handle cases where Promise fulfillment is essentially triggered synchronously. JS has an internal "Promise queue" that ensures consistent ordering with Promise resolution and fulfillment, assuming all Promises of equal priority. Its func exists to customize their order of resolution when fulfilled "synchronously", based on a supplied
priority
value - as we will prefer matchers for specific gesture models to always be checked before those of lower priority.The included unit tests should be clear and concise enough to illustrate the intended use of the new class and the sort of problem it's meant to solve.
@keymanapp-test-bot skip