Skip to content
This repository has been archived by the owner on Dec 23, 2022. It is now read-only.

Support using event.key or .code instead of deprecated keyCode #271

Closed
geirsagberg opened this issue Apr 20, 2019 · 5 comments
Closed

Support using event.key or .code instead of deprecated keyCode #271

geirsagberg opened this issue Apr 20, 2019 · 5 comments

Comments

@geirsagberg
Copy link

geirsagberg commented Apr 20, 2019

TL;DR: Would like to use e.g. newChipKeys={['Enter', 'Tab']} instead of or in addition to newChipKeyCodes={[13, 9]}

I am using ChipInput for an email input field.
I noticed some strange behavior, having set newChipKeyCodes to [9, 13, 187, 188] in order to trigger on Tab, Enter, SemiColon and Comma (on norwegian keyboards).
When I was entering an email with a plus sign in it, that also triggered. Did some digging, and turns out keyCodes are different depending on keyboard language, so e.g. SemiColon is keyCode 187 for norwegian layout, but code 186 for US layouts; in US layouts, 187 is the code for plus or equals.

According to MDN, keyCodes are deprecated, and the replacement is to use either KeyboardEvent.code or KeyboardEvent.key.

Not sure which one of key and code would be most fitting here, but either one of them is probably better than keyCode.

@leMaik
Copy link
Member

leMaik commented Apr 21, 2019

Good point! 👍 I'm not sure about using key or code either. There might be use cases for both. How should we proceed?

  1. It would be nice to add a callback function for full controll, e.g. shouldAddChip={e => e.key === 'Enter'}. That would be very flexible, but also very complex.
  2. Adding newChipKeys and newChipCodes? That seems a bit redundant.
  3. Adding newChipKeys (might be the most common case), deprecating newChipKeyCodes and adding shouldAddChip for those who want to use code for some reason?

If you want to give it a try, please feel free to submit a PR! 😎

@leMaik
Copy link
Member

leMaik commented Aug 20, 2019

From MDN:

For example, the code returned is "KeyQ" for the "q" key on a QWERTY layout keyboard, but the same code value also represents the "'" key on Dvorak keyboards and the "a" key on AZERTY keyboards. That makes it impossible to use the value of code to determine what the name of the key is to users if they're not using an anticipated keyboard layout.
To determine what character corresponds with the key event, use the KeyboardEvent.key property instead.

TL;DR: key, it is.

@leMaik leMaik closed this as completed in 4ff3ce9 Aug 20, 2019
leMaik added a commit that referenced this issue Aug 20, 2019
@leMaik
Copy link
Member

leMaik commented Aug 20, 2019

I'll publish this as v1.1.0 and v2.0.0-beta.2 tomorrow. 😴

@akrz
Copy link

akrz commented Nov 24, 2019

@leMaik Did you publish the v2.0.0-beta.2? I'm not seeing it in the releases.

@leMaik
Copy link
Member

leMaik commented Dec 1, 2019

@akrz Whoops... Well, here they are: v1.1.0 and v2.0.0-beta.2

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

3 participants