Link to package:
https://www.npmjs.com/package/keycode

• Add dependency
• Use keycode instead of array
• Remove keycodes in-built array

Add a 'character' property to keypress events which cleans up the characters (removes special character presses etc.

add an additional field, with display names for the keys pressed, held, or released

say 3 or 5

suggested by @sairamindia

I try to use it with typescript:

import xs, { Stream } from 'xstream'

const up$: Stream<number> = keyboard.downs('up').mapTo(1)

but got types errors:

error TS2322: Type 'Stream<number>' is not assignable to type 'Stream<number>'.
  Property '_ils' is protected but type 'Stream<T>' is not a class derived from 'Stream<T>'.

Everything works fine without types.

[email protected]
[email protected]
[email protected]
[email protected]
[email protected]

Real world example: https://github.com/Nitive/battle-city/blob/b3cb06e/src/index.ts#L15-L18

• Add ups()
• Add downs()
• Add presses()

We might miss alias names if we check the current way:

if(typeof key === 'string')
  return keyUp$.filter(ev => ev.displayKey === key);

We are better off using

if(typeof key === 'string')
  return keyUp$.filter(ev => ev.keyCode === keycode.codes[key]);

I'm using a self-built array, sourced from http://keycode.info/
The cycle-keys driver uses a keycode library.

Which do you feel is better, and more comprehensive?

Please comment.

Given a named key or keycode, this stream will return a boolean indicating whether the key is currently down.

This is a useful stream to have especially for game development, and I have implemented it before in my own Keys Driver. I think it would be a handy method to have in this driver.

I think since keydown.preventDefault() is called, caps lock, shift, and keypress are not occurring.

The keyboard events javscript api is well known, with event.target, event.keyCode etc. Encapsulating the original event seems like a bad API. Why not add properties displayKey and displayChar to the original event itself and return it?

From our gitter conversation:

Sudarsan Balaji @artfuldev 14:53

@Widdershin I initially thought that keyboard.keyUp$.filter(ev => ev.displayKey == 'Ctrl') was a better API (because it conveys intent) than keyboard.keyUp('Ctrl'). Is that at fault?

Nick Johnstone @Widdershin 14:54

do all browsers support displayKey?

Sudarsan Balaji @artfuldev 14:54

It's a property that the driver adds

Nick Johnstone @Widdershin 14:54

ohhh
interesting
I think I would still prefer the latter because it's my most common use case
but I can see the value of your style

Sudarsan Balaji @artfuldev 14:56

@Widdershin I would like to see which people prefer. We could obviously provide both, but it will make the API clobbered with too many functions offering the same. OTOH some APIs provide shortcut functions exposing the same functionality, so it may be acceptable. We should perhaps open up a discussion? Or are you extremely certain that the latter is the way to go?

Raquel Moss @raquelxmoss 14:58

@artfuldev I reckon we should discuss API (and/or copy some of this conversation over to) on Github. It might be nice to have some history on the repo that covers the why of decision making around the API

Sudarsan Balaji @artfuldev 14:58

@raquelxmoss good call.

cycle-keyboard version in the app should be upgraded to 1.0.0-rtm.1