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.

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

Already on GitHub? Sign in to your account

chore(web): fixes implicit-this cases 馃敥 #11459

Merged
merged 4 commits into from
May 30, 2024

Conversation

jahorton
Copy link
Contributor

@jahorton jahorton commented May 16, 2024

Addresses part of #11473, correcting all remaining cases caught by enforcing `"noImplicitThis" across all Keyman Engine for Web related code.

@keymanapp-test-bot skip

@keymanapp-test-bot keymanapp-test-bot bot added this to the A18S2 milestone May 16, 2024
@jahorton jahorton changed the title chore(web): fixes implicit this cases chore(web): fixes implicit-this cases May 16, 2024
@mcdurdin
Copy link
Member

Can you include a reference for why this is being done? (It's part of a larger task, right?)

Comment on lines 6 to 9
// TODO: These override ../tsconfig.base.json settings, and so should be removed if possible,
// but existing code in web/ breaks some of these settings
"noImplicitAny": false,
"noImplicitThis": false,
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Why this is being done: the // TODO: above.

Comment on lines 16 to 22
if(osk.vkbd.menuEvent) {
this.highlightKey(osk.vkbd.menuEvent, false);
}
if(typeof(engine.menuKeyUp) == 'function') { // VisualKeyboard event: globeKey
engine.menuKeyUp();
}
osk.vkbd.menuEvent = null;
Copy link
Member

Choose a reason for hiding this comment

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

This change doesn't seem to belong? Seems like a difference in behaviour.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

See line 26. It's not immediately obvious, but osk.vkbd.menuEvent would hold the same value as key for this event. We were de-highlighting the key twice.

Secondly, note that there was no reasonable this that actually had a highlightKey function; that in itself needed correcting. This should have triggered null or undefined-reference errors, yet we've never seen anything arise from this block of code. The code path is actually dead, but I felt removing the whole thing would be an even bigger change.

Comment on lines 27 to 28
var event = Pelem as Event;

if(this.instanceof(event.target, 'Window')) {
scopedClass = event.target[className];
} else if(this.instanceof(event.target, 'Document')) {
scopedClass = (event.target as Document).defaultView[className];
} else if(this.instanceof(event.target, 'HTMLElement')) {
scopedClass = (event.target as HTMLElement).ownerDocument.defaultView[className];
}
const event = Pelem as Event;
return nestedInstanceOf(event.target, className);
Copy link
Member

Choose a reason for hiding this comment

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

This also looks like a behavioural change?

Copy link
Contributor Author

@jahorton jahorton May 17, 2024

Choose a reason for hiding this comment

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

Another case of "there's no reasonable this supporting the specified method." Turns out, we have no cases of calling nestedInstanceOf with an event object; we'd have been getting null/undefined errors otherwise. The code path is actually dead at the moment.

That said, were we to change paths on this fact in the future, the easiest approach is to simply get the event target and act as if that was the original parameter. Compare with lines 20-25 - they're checking for the same things once we substitute event.target in for Pelem.

Copy link
Member

@mcdurdin mcdurdin left a comment

Choose a reason for hiding this comment

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

LGTM. Sounds like there are some dead code removal PRs coming up before too long as well?

@mcdurdin mcdurdin modified the milestones: A18S2, A18S3 May 24, 2024
@jahorton jahorton marked this pull request as draft May 28, 2024 02:39
@jahorton jahorton force-pushed the chore/web/fix-implicit-this branch from eef8c32 to a5c10e8 Compare May 29, 2024 01:54
@jahorton jahorton changed the base branch from chore/web/partial-config-cleanup to fix/web/remove-dead-branches May 29, 2024 01:54
@jahorton jahorton marked this pull request as ready for review May 29, 2024 01:54
@jahorton jahorton changed the title chore(web): fixes implicit-this cases chore(web): fixes implicit-this cases 馃敥 May 29, 2024
Base automatically changed from fix/web/remove-dead-branches to master May 30, 2024 08:50
@jahorton jahorton merged commit dbee817 into master May 30, 2024
19 checks passed
@jahorton jahorton deleted the chore/web/fix-implicit-this branch May 30, 2024 08:50
@keyman-server
Copy link
Collaborator

Changes in this pull request will be available for download in Keyman version 18.0.45-alpha

@keyman-server
Copy link
Collaborator

Changes in this pull request will be available for download in Keyman version 18.0.45-alpha

2 similar comments
@keyman-server
Copy link
Collaborator

Changes in this pull request will be available for download in Keyman version 18.0.45-alpha

@keyman-server
Copy link
Collaborator

Changes in this pull request will be available for download in Keyman version 18.0.45-alpha

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

Successfully merging this pull request may close these issues.

None yet

4 participants