liferay / liferay-frontend-projects

A monorepo containing assorted Frontend Infrastructure Team projects
Other
69 stars 68 forks source link

Standardize events to use `key` instead of `keyCode` #326

Open diegonvs opened 4 years ago

diegonvs commented 4 years ago

What is your proposal?

Adds a utility for mapping keyCode values, because we're creating a lot of repeated mapping for it on our DXP.

Why would adopting this proposal be beneficial?

Facilitate the work when working with keydown events and avoid repetitions on our code.

What are the alternatives to this proposal?

  1. Left it as is? 🤔
  2. Adopt a dependency for it(frontend infra team will be sad with this 😢 😭)
wincent commented 4 years ago

Step 1 here, I suggest, would be compiling a list of places where we're using key events, to get a sense of how key codes are being used, and how broad we should aim for our coverage to be.

As a rough sketch, git grep -i '\b(keyup|keydown|keypress)\b' -- '*.js' '*.jsp' '*.jspf' | egrep '^modules/(apps|dxp)/' | perl -pe 's%^(.+?):(\d+).+$%- [$1:$2](https://github.com/liferay/liferay-portal/blob/5541574134ec/$1#L$2)%':

Just sampling a few of those places, it seems worthwhile to add a common mapping.

jbalsas commented 4 years ago

goforit

edalgrin commented 4 years ago

I know it's just a list with the keys map but is this the right choice from an accessibility point of view?

//cc @marcoscv-work

diegonvs commented 4 years ago

Just for update here:

Should We consider moving to standardize key instead of keyCodes 😅 ?

Considering:

wincent commented 4 years ago

We consider moving to standardize key instead of keyCodes

Probably. We'd need to tackle this on two fronts: in React (synthentic events) and in JS using native DOM events. And in terms of enforcement/encouragement we can try to force all key-related event handling through a central API, but that means both writing the API and creating a lint to make sure it's actually used.

In terms of priority for such work, I get that consistency etc is attractive, but I also have the gut feeling that doing all of this work may not yield a large impact, because we seem to be coming to it from a perspective of wanting to follow best practices and not because we've identified a pattern of regressions and degraded product quality. Which is not to say that we shouldn't do it, but just that we should be clear on when/why we would do it instead of other things.

bryceosterhaus commented 3 years ago

Using this issue for standardizing key => keyCode with an eslint rule

Additionally, we might want to use a codemod for updating DXP uses.