-
-
Notifications
You must be signed in to change notification settings - Fork 33.7k
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(core): support KeyboardEvent.key for built in keyboard event modifiers, fix #6900 #7121
Conversation
src/compiler/codegen/events.js
Outdated
@@ -16,6 +16,18 @@ const keyCodes: { [key: string]: number | Array<number> } = { | |||
'delete': [8, 46] | |||
} | |||
|
|||
const keyNames: { [key: string]: string | Array<string> } = { |
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.
Why not just move the keyNames and keyCodes to runtime instead of in the compiler? Since it leads sooo much repetition and should reduce the code size.
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.
Actually in my first version, I did define keyNames
in check-keycodes.js
. After that I realize this would increase much runtime bundle size, so I got it moved into compiler...
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.
I guess the reason keyCodes
stays in compiler is that it simply generate numbers rather strings. Agreed for moving keyNames
into runtime.🙂
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.
Ya, considering all compiled templates size together, it could reasonable to move them into runtime. BTW, seems it has not that much different to deal with keyCodes and keyNames.
What kind of change does this PR introduce? (check at least one)
Does this PR introduce a breaking change? (check one)
If yes, please describe the impact and migration path for existing applications:
The PR fulfills these requirements:
dev
branch for v2.x (or to a previous version branch), not themaster
branchfix #xxx[,#xxx]
, where "xxx" is the issue number)If adding a new feature, the PR's description includes:
Other information:
#6900