Skip to content
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(FEC-9481): distributed keyboard handler to decorator #464

Merged
merged 30 commits into from
Jan 2, 2020
Merged

Conversation

Yuvalke
Copy link
Contributor

@Yuvalke Yuvalke commented Dec 5, 2019

Description of the Changes

create keyboard decorator event to implement in each component which use keyboard event on player area.

Solves: FEC-9481

CheckLists

  • changes have been done against master branch, and PR does not conflict
  • new unit / functional tests have been added (whenever applicable)
  • test are passing in local environment
  • Travis tests are passing (or test results are not worse than on master branch :))
  • Docs have been updated

create keyboard decorator event to implement in each compnent which use keyboard event on player area.
src/components/keyboard/index.js Show resolved Hide resolved
src/components/keyboard/keyboard-event-provider.js Outdated Show resolved Hide resolved
* @private
*/
_shouldHandledKeyboardEvent(): boolean {
return this.props.isKeyboardEnable && !this.props.shareOverlay && !this.props.playerNav;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

share overlay can set isKeyboardEnable: false by itself instead of this, no?

Copy link
Contributor Author

@Yuvalke Yuvalke Dec 26, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, if user will change the isKeyboardEnable to false and then share will change it to false as well and then true the final state of isKeyboardEnable will be true and that's not what the user wants.
There is another solution that could contain internalKeyboard state and externalKeyboard state but I don't think it's needed here.

src/components/keyboard/with-keyboard-event.js Outdated Show resolved Hide resolved
src/components/keyboard/with-keyboard-event.js Outdated Show resolved Hide resolved
@@ -76,6 +79,38 @@ class Language extends Component {
*/
componentDidMount() {
this.props.eventManager.listen(document, 'click', e => this.handleClickOutside(e));
this.props.addKeyboardHandler({code: KeyMap.C}, event => {
event.preventDefault();
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

import this handler from keyboard.js. we can't maintain code like this twice.
same for all new handlers in this change

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we'll not.
keyboard.js is deprecated if someone wants to use it he'll need to write the logic by himself I don't think we need to maintain this code anymore.

if (!this._keyboardListeners[keyCode]) {
this._keyboardListeners[keyCode] = callback;
}
window.console.log(this._keyboardListeners[keyCode]);
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

delete

* @private
*/
_shouldHandledKeyboardEvent(): boolean {
return this.props.isKeyboardEnable && !this.props.shareOverlay && !this.props.playerNav;
Copy link
Contributor Author

@Yuvalke Yuvalke Dec 26, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, if user will change the isKeyboardEnable to false and then share will change it to false as well and then true the final state of isKeyboardEnable will be true and that's not what the user wants.
There is another solution that could contain internalKeyboard state and externalKeyboard state but I don't think it's needed here.

@@ -76,6 +79,38 @@ class Language extends Component {
*/
componentDidMount() {
this.props.eventManager.listen(document, 'click', e => this.handleClickOutside(e));
this.props.addKeyboardHandler({code: KeyMap.C}, event => {
event.preventDefault();
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we'll not.
keyboard.js is deprecated if someone wants to use it he'll need to write the logic by himself I don't think we need to maintain this code anymore.

* @extends {Component}
*/
class KeyboardEventProvider extends Component {
_events: Object = {keydown: 1, keyup: 2, keypress: 3};
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

* @returns {void}
*/
componentWillUnmount(): void {
const {eventManager, playerContainer} = this.props;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

withEventManager destroys the event manager on componentWillUnmount, so no need for this

* @memberof withKeyboardEvent
*/
render(): React$Element<any> | void {
return <WrappedComponent {...this.props} registerEvents={eventHandlers => this.registerEvents(eventHandlers)} />;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

registerEvents as an API is too generic name.
If we are passing this as named prop it should be understood it is addKeyboardBindings or addKeyboardEvent


_keyboardEventHandlers: Array<KeyboardEventHandlers> = [
{
eventType: 'keydown',
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

each event should have
{
eventType?,
key,
handler
}

cause each key binding can have different eventType potentially
Also, eventType should be optional cause keyDown is the default

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I grouped by eventType to make it clear
[{eventType:keydown,
handlers:[]}]

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Handler -> {key:keyboardKey, action:function}

@Yuvalke Yuvalke changed the title feat(FEC-9481): Distributed Keyboard handler to decorator feat(FEC-9481): distributed keyboard handler to decorator Jan 1, 2020
@yairans yairans self-requested a review January 2, 2020 09:17
@yairans yairans dismissed their stale review January 2, 2020 09:18

changes done

OrenMe
OrenMe previously approved these changes Jan 2, 2020

const COMPONENT_NAME = 'KEYBOARD_PROVIDER';

export const keyboardEvents: Object = {keydown: 1, keyup: 2};
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ENUM is CAPITAL snake case KEYBOARD_EVENTS KEYDOWN KEYUP

@Yuvalke Yuvalke merged commit af71c20 into master Jan 2, 2020
@Yuvalke Yuvalke deleted the FEC-9481 branch January 2, 2020 12:42
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

Successfully merging this pull request may close these issues.

None yet

3 participants