Adds new `handledKeys` prop to handle more than one key

[aarosil]

Thanks for the nice library!

I saw in the issues a lot of requests to let this library handle multiple keys, so I took a stab at it.

• The KeyHandler component takes a new prop called handledKeys which is basically an array of shape keyValue, keyCode, and a new prop I added called allowInputTarget which allows the event to pass even if it's target is an input (I have the use case to listen to 'Escape' key from inputs).
• The keyHandler HOC also takes a new prop called handleKey, and if present, it passes that to KeyHandler component as the value of onKeyHandle, instead of it's own this.handleKey. This lets you take control and handle all the key events with your own function without using the KeyHandler component directly.

Assuming you had some component with following methods:

handleKeyEvent(e) {
  switch(e.key) {
    case 'Escape':
      return console.log('hit escape');

    case 'ArrowLeft':
      return console.log('navigated direction');
  }
}

get handledKeys() {
  return [
    { keyValue: 'Escape', allowInputTarget: true },
    { keyCode: 37 }
  ];
}

You could use it like this:

<KeyHandler
  keyEventName={KEYDOWN}
  handledKeys={this.handledKeys}
  onKeyHandle={this.handleKeyEvent} />

Should also work the same using as a HOC.

Let me know if this looks good to you and I can try adding some unit tests for this behavior.

[ayrton]

First of all I wanna say this is awesome, I somehow missed this PR so sorry for the late reply.

I like the direction where this is heading, but I think the ideal API looks something like this:

<KeyHandler
  keyValues={['Escape', 'ArrowLeft']}
  onKeyHandle={this.handleKeyEvent} />

Correct me if I'm wrong but I don't think we need to intro allowInputTarget if you specify the right keyEventName (in this case the default should do)

[aarosil]

I too apologize for late reply. Glad to hear you like this suggestion!

I had mentioned previous issues in the repo about multiple keys, but upon closer reading, I noticed those were about binding to multiple keys at the same time (cmd + whatever for example), so I just wanted to clarify that this PR isn't doing that, but just lets you configure a single KeyHandler to handle multiple keys.

Anyway, that is why key values was array of objects instead of just the keyValue string names, to keep the same config options as someone had before. But I can update so it is just an array of the keyValue string names also if you preferred that. Also, I think you're right that allowInputTarget not needed.

[ayrton]

@aarosil in that case what do you think if keyValue can either be a string or an array of strings to avoid confusion. That way we don't introduce a new prop, and we can still use keyValues for combinations of keys

[gforge]

I agree that keyCode/keyValue could be either string or array. Having additional options could cause confusion when using both.

[gforge]

I took the liberty of writing my own array handler + adding the code key to the package: https://github.com/gforge/react-key-handler/tree/add_code_and_array

I also took the liberty of refactoring a little - the index.js is more informative and the decorator has moved into a separate file.

There is also 1 major change and that is that I removed the priority of inputs. It seems to me that either you throw an error when mounting the component with both keyValue and keyCode specified or you look and see if any of them match.

The README and demo's are also updated.

Let me know if you want this as a PR, I'll probably release a scoped package version otherwise for my own convenience :grin:. Thanks again for this awesome package!

[ayrton]

@gforge feel free to open a PR! I can have a look this week

[ayrton]

Closing in favour of #148 (which is closed to being merged in)