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’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

chore(web): clean up remaining low-level Web .tsconfig settings 🔩 #11424

Merged
merged 14 commits into from
Jun 3, 2024

Conversation

jahorton
Copy link
Contributor

@jahorton jahorton commented May 13, 2024

This PR serves to finish off #11473 for all Keyman Engine for Web code outside ${KEYMAN_ROOT}/web.

This used to be earlier in the chain, but now multiple related bug fixes detected due to the enhanced settings have been hoisted into what are now ancestor PRs.

@keymanapp-test-bot skip

Comment on lines 14 to 19
// TODO: These override ../tsconfig.base.json settings, and so should be removed if possible,
// but existing code in web/ breaks some of these settinsg
"noImplicitThis": false,
"noImplicitReturns": false,
"noImplicitAny": false,
"strictFunctionTypes": false,
"noUnusedLocals": 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.

The big motivator: cleaning this up. I was able to push it back significantly outside of web/ (and common/web/gesture-recognizer).

Copy link
Contributor Author

Choose a reason for hiding this comment

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

The latter: any TS compilation errors encountered by mocha when loading tests are not passed through, leaving the cause somewhat opaque.

I resolve these over the following PRs, one flag at a time, along with the corresponding settings in web/.

@jahorton jahorton force-pushed the chore/web/update-typescript branch from ecd68fb to 408fe43 Compare May 15, 2024 06:11
@jahorton jahorton force-pushed the chore/web/partial-config-cleanup branch 2 times, most recently from 369ecb8 to 92ffb33 Compare May 16, 2024 02:37
@jahorton jahorton force-pushed the chore/web/update-typescript branch from 408fe43 to d70463a Compare May 16, 2024 02:38
@jahorton jahorton marked this pull request as ready for review May 22, 2024 15:02
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.

There are a lot of changes here which appear to be bug fixes. I guess I would like to know if they have any tangible impact on behaviour of KeymanWeb, and if any of them should be back-ported to 17.0-stable. Any fixes that have a tangible impact should probably have separate issues opened so that we can track them. I know that's a bunch of work, but bundling all the fixes together otherwise makes it really hard to track behavioural changes as a result of this PR.

If you could add reasons in comments for the @ts-ignores (some are reasonably obvious I guess but not all of them), that would also be great.

common/web/keyboard-processor/src/text/codes.ts Outdated Show resolved Hide resolved
common/web/keyboard-processor/src/text/kbdInterface.ts Outdated Show resolved Hide resolved
common/web/lm-worker/src/main/model-compositor.ts Outdated Show resolved Hide resolved
common/web/recorder/src/index.ts Outdated Show resolved Hide resolved
common/web/recorder/src/index.ts Outdated Show resolved Hide resolved
Copy link
Contributor Author

@jahorton jahorton left a comment

Choose a reason for hiding this comment

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

I'll have to pause here for now re: the questions in the comments, but figured I could go ahead and submit my current progress.

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.

I just wanted to follow up on a couple of the Promise<> return values because I think the scenarios are more complex than you maybe had anticipated. Hope this helps!

Copy link
Contributor Author

@jahorton jahorton left a comment

Choose a reason for hiding this comment

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

OK, that should complete the first pass-through. I'll be using my own replies to help track what needs handling in what ways; apologies for any notification-noise this causes.

common/web/keyboard-processor/src/text/kbdInterface.ts Outdated Show resolved Hide resolved
common/web/lm-worker/src/main/model-compositor.ts Outdated Show resolved Hide resolved
common/web/recorder/src/index.ts Outdated Show resolved Hide resolved
common/web/recorder/src/index.ts Outdated Show resolved Hide resolved
@jahorton
Copy link
Contributor Author

jahorton commented May 23, 2024

There are a lot of changes here which appear to be bug fixes. I guess I would like to know if they have any tangible impact on behaviour of KeymanWeb, and if any of them should be back-ported to 17.0-stable. Any fixes that have a tangible impact should probably have separate issues opened so that we can track them. I know that's a bunch of work, but bundling all the fixes together otherwise makes it really hard to track behavioural changes as a result of this PR.

So, it sounds like the implication is that I should...

  1. Put this back into draft
  2. Create separate PRs for any noted bug fixes (possibly with associated issues)
  3. Base the remainder of this PR after those separate PRs.

This PR can't proceed well without resolving said issues, so "the remainder" - which is intended as the main point of this PR - depends on the fixes existing either before or at the same time within commit history.

I remember there being some other noted issues in some of the follow-ups, so it may be worth bumping those changes up as part of step 2.

@mcdurdin
Copy link
Member

So, it sounds like the implication is that I should...

  1. Put this back into draft
  2. Create separate PRs for any noted bug fixes (possibly with associated issues)
  3. Base the remainder of this PR after those separate PRs.

Yes, that would be great, thanks. That'll make it really easy to cherry-pick any fixes that we think need to be back-ported as well. Sorry for the hassle!

I remember there being some other noted issues in some of the follow-ups, so it may be worth bumping those changes up as part of step 2.

Sounds good to me.

@jahorton jahorton force-pushed the chore/web/partial-config-cleanup branch from 01be6f6 to 12c91d9 Compare May 29, 2024 03:36
@jahorton jahorton changed the base branch from refactor/web/typed-property-transplantation to fix/web/kbd-proc-strictness-bugs May 29, 2024 03:37
@jahorton jahorton requested a review from mcdurdin May 29, 2024 03:37
@jahorton jahorton marked this pull request as ready for review May 29, 2024 03:37
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.

This is looking clean now, good work. LGTM

@@ -30,15 +30,42 @@ export interface VariableStoreDictionary {
[name: string]: string;
};

export type KeyboardObject = {
Copy link
Member

Choose a reason for hiding this comment

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

Is this the only definition we have anywhere for this type? It feels like it belongs in common/web/types in the future, with copious comments...

Copy link
Contributor Author

Choose a reason for hiding this comment

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

So far as I can tell, yes. I always did want to write up a formal type for it, and this push gave the perfect excuse.

I'd be happy for the type to be hoisted to common/web/types; be my guest!

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I just went ahead and added documentation for all fields.

Comment on lines +437 to +441
let sample: Suggestion & {
p?: number,
"lexical-p"?: number,
"correction-p"?: number
} = value.sample;
Copy link
Member

Choose a reason for hiding this comment

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

Where else would this type be used?

Copy link
Contributor Author

@jahorton jahorton May 30, 2024

Choose a reason for hiding this comment

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

These fields are currently only used for debugging; I've found them helpful in the past when determining what influenced the suggestions being displayed and how strongly earlier suggestions "won" over later ones. These pass through the lm-layer -> Web-engine boundary and are available for the Suggestion objects held by the suggestion banner, allowing them to be viewable without needing any breakpoints.

Without these two fields, the values they represent are locked within a limited time-window within the lm-worker, requiring breakpoints at the right location.


Of note: p, at least, would be very useful for implementing autocorrect. There's a chance one of the other two would be relevant as well. For example, we may wish to require much stricter keystroke input ("correction") for rarer words, possibly raising the overall threshold required to trigger for such cases.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

The closest related issue I could find re: autocorrect: #1841. There doesn't seem to be a baseline "autocorrect" issue, but #1841 at least references the notion of autocorrect.

Comment on lines 156 to 160
/**
* Virtual Key Dictionary: the engine pre-processed, unminified dictionary. This is built within
* Keyman Engine for Web at runtime as needed based on the definitions in `KVKD`.
*/
VKDictionary?: Record<string, number>,
Copy link
Member

Choose a reason for hiding this comment

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

I reckon we should put VKDictionary and _kmw into a subclass, as they are internal to Keyman Engine for Web. But that can wait until we move to common/web/types.

Co-authored-by: Marc Durdin <marc@durdin.net>
Copy link
Contributor

@ermshiperete ermshiperete left a comment

Choose a reason for hiding this comment

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

👍 I like these type definitions with comments!

K102?: boolean,
/**
* Keyboard Layer Specification: an object-based map of layer name to the keycaps for its
* 65 keys. The 65 keys are ordered from left to right, then top to bottom.
Copy link
Contributor

Choose a reason for hiding this comment

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

Why 65 (keys)?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Took some digging, but I found it.

This array is precisely 65 entries long and maps each index of the 65 to its represented hardware key. Note that some are reserved - that's the role of K_*.

static readonly dfltCodes: ReadonlyArray<string> = [
"K_BKQUOTE","K_1","K_2","K_3","K_4","K_5","K_6","K_7","K_8","K_9","K_0",
"K_HYPHEN","K_EQUAL","K_*","K_*","K_*","K_Q","K_W","K_E","K_R","K_T",
"K_Y","K_U","K_I","K_O","K_P","K_LBRKT","K_RBRKT","K_BKSLASH","K_*",
"K_*","K_*","K_A","K_S","K_D","K_F","K_G","K_H","K_J","K_K","K_L",
"K_COLON","K_QUOTE","K_*","K_*","K_*","K_*","K_*","K_oE2",
"K_Z","K_X","K_C","K_V","K_B","K_N","K_M","K_COMMA","K_PERIOD",
"K_SLASH","K_*","K_*","K_*","K_*","K_*","K_SPACE"
];

Copy link
Contributor Author

Choose a reason for hiding this comment

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

In regard to how they're linked:

Web has a built-in default desktop layout, listing the key IDs at each position.

"desktop":
{
"defaultHint": 'dot',
"font": "Tahoma,Helvetica",
"layer": [
{
"id": "default",
"row": [
{
"id": 1,
"key": [
{ "id": "K_BKQUOTE" },
{ "id": "K_1" },
{ "id": "K_2" },
{ "id": "K_3" },
{ "id": "K_4" },
{ "id": "K_5" },

When iterating through this default layout, we take the key ID and look up its position among the 65.

// *** Step 2: Layer objects now exist; time to fill them with the appropriate key labels and key styles ***
for(n=0; n<layers.length; n++) {
var layer=layers[n], kx, shiftKey: LayoutKey = null;
var capsKey: LayoutKey = null, numKey: LayoutKey = null, scrollKey: LayoutKey = null; // null if not in the OSK layout.
var layerSpec = keyLabels[layer['id']];
var isShift = layer['id'] == 'shift' ? 1 : 0;
var isDefault = layer['id'] == 'default' || isShift ? 1 : 0;
rows=layer['row'];
for(i=0; i<rows.length; i++) {
keys=rows[i]['key'];
for(j=0; j<keys.length; j++) {
key=keys[j];
kx=Layouts.dfltCodes.indexOf(key['id']);

@jahorton jahorton changed the title chore(web): remaining low-level Web .tsconfig cleanup 🔩 chore(web): clean up remaining low-level Web .tsconfig settings 🔩 Jun 3, 2024
Base automatically changed from fix/web/kbd-proc-strictness-bugs to master June 3, 2024 03:55
@jahorton jahorton merged commit 604d2fc into master Jun 3, 2024
19 checks passed
@jahorton jahorton deleted the chore/web/partial-config-cleanup branch June 3, 2024 08:16
@keyman-server
Copy link
Collaborator

Changes in this pull request will be available for download in Keyman version 18.0.47-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