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

Feature/enyo 4811 roysutton #1301

Merged
merged 19 commits into from
Nov 16, 2017
Merged

Feature/enyo 4811 roysutton #1301

merged 19 commits into from
Nov 16, 2017

Conversation

webOS101
Copy link
Contributor

@webOS101 webOS101 commented Nov 10, 2017

Issue Resolved / Feature Added

Marquee would not continue or start in certain situations. Additionally, Spottable was not
correctly forwarding onMouseEnter and onMouseLeave.

Resolution

Modify MarqueeDecorator to not start or stop its own marquee when controlled,
deferring that instead to MarqueeController. Additionally, keep track of hover status
in MarqueeDecorator when enabled so we can keep the status when switching to
disabled. MarqueeController is modified to add callbacks for enter and leave
so it can track the hover state of controls. Also, added a delay before stopping
controlled marquee so that moving among controls does not cause stuttering
marquee. Finally, added some code to PickerButton to trap hover so we can
start marquee when hovering disabled buttons.

Additional Considerations

We may need a new qa sample to demonstrate controlled marquees that use
marqueeOn focus and disabled marqueeOn focus components.

Links

ENYO-4811
ENYO-4882
ENYO-4907
ENYO-4910

Comments

Roy Sutton and others added 13 commits November 9, 2017 18:26
Enact-DCO-1.0-Signed-off-by: Roy Sutton roy.sutton@lge.com
Enact-DCO-1.0-Signed-off-by: Roy Sutton roy.sutton@lge.com
Enact-DCO-1.0-Signed-off-by: Roy Sutton roy.sutton@lge.com
Enact-DCO-1.0-Signed-off-by: Roy Sutton roy.sutton@lge.com
Enact-DCO-1.0-Signed-off-by: Roy Sutton roy.sutton@lge.com
Enact-DCO-1.0-Signed-off-by: Roy Sutton roy.sutton@lge.com
Enact-DCO-1.0-Signed-off-by: Roy Sutton roy.sutton@lge.com
Enact-DCO-1.0-Signed-off-by: Roy Sutton roy.sutton@lge.com
Enact-DCO-1.0-Signed-off-by: Roy Sutton roy.sutton@lge.com
Enact-DCO-1.0-Signed-off-by: Roy Sutton roy.sutton@lge.com
Copy link
Contributor

@viodragon2 viodragon2 left a comment

Choose a reason for hiding this comment

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

Made some changes for LabeledItem. Other than that everything looks good to me 👍

Copy link
Contributor

@aarontam aarontam left a comment

Choose a reason for hiding this comment

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

Some initial comments/questions. Taking a deeper dive still.

this.cancelJob.stop();
}

cancelJob = new Job(() => this.doCancel(), 30)
Copy link
Contributor

Choose a reason for hiding this comment

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

30 seems like a magic number - what was the reasoning behind the specific value?

Copy link
Contributor Author

@webOS101 webOS101 Nov 15, 2017

Choose a reason for hiding this comment

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

It is a bit magical. It was supposed to be long enough to make it async but not so long that the user would notice a lag between unhovering/unspotting and the marquee stopping. It should be long enough that as the move they pointer between the different parts of a controlled set that it wouldn't reset. I was thinking 100-300ms was probably a reasonable number but 30 seems to work well in testing. It may be possible to go without it given the ordering of the events but I didn't want to rely on possibly unpredictable event ordering.

Copy link
Contributor

@aarontam aarontam Nov 16, 2017

Choose a reason for hiding this comment

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

🎩 🐰

Admittedly feels a bit dirty...

@@ -44,7 +44,7 @@ describe('LabeledItem Specs', () => {
});

it('should have \'disabled\' HTML attribute when \'disabled=true\'', function () {
const item = mount(
const item = shallow(
Copy link
Contributor

Choose a reason for hiding this comment

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

Assuming we couldn't do a shallow test here, there should be a cleaner way to write this test so that we aren't checking the specific number of elements (1) with a disabled prop set to true.

Copy link
Contributor

Choose a reason for hiding this comment

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

onFocus: this.handleFocus
onFocus: this.handleFocus,
// When picker button becomes disabled, it doesn't fire blur, but does fire
// `onSpotlightDisappear`. We should investigate why `onBlur` does not fire
Copy link
Contributor

Choose a reason for hiding this comment

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

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Interesting find! Could be related. Talked some with @germboy about it but we didn't reach any conclusions.

return null;
});
if (!this.sync) {
this.setState((prevState) => {
Copy link
Contributor

Choose a reason for hiding this comment

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

Worth throwing this into a fn?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

:indeed:

@@ -26,10 +28,35 @@ const PickerButtonBase = kind({
spotlightDisabled: PropTypes.bool
},

defaultProps: {
joined: false
Copy link
Contributor

Choose a reason for hiding this comment

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

Is this necessary?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

No, not any longer since I removed forProp(). Just forgot to clean it up.

@@ -299,6 +299,8 @@ const MarqueeDecorator = hoc(defaultConfig, (config, Wrapped) => {
this.textDirectionValidated = false;
} else if (next.marqueeOn !== marqueeOn || next.marqueeDisabled !== marqueeDisabled || next.marqueeSpeed !== marqueeSpeed) {
this.cancelAnimation();
} else if (next.disabled && this.isHovered && marqueeOn === 'focus' && this.sync) {
Copy link
Contributor

Choose a reason for hiding this comment

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

Can you explain how the marqueeOn === 'focus' check helps in this scenario?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

In this scenario, we're checking for a transition to disabled when we were in 'focus' start. In this case, we could get a 'blur' event, which would cancel the marquee. Since we're hovered, we want to make sure the marquee continues.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Not to mention that we don't fire the 'enter' event when focused and enabled.

if (!this.anyRunning()) {
this.dispatch('start');
}
this.cancelJob.stop();
Copy link
Contributor

Choose a reason for hiding this comment

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

Do we need to stop the job if we're hovered now? Will the job's fn exit early?

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 -could- rely on the job to run out and be trapped by the hover event. It seemed wiser to always clean up the job than to rely on logic elsewhere. I'm game for removing these extra ones.

if (!this.anyRunning()) {
this.dispatch('start');
}
this.cancelJob.stop();
Copy link
Contributor

Choose a reason for hiding this comment

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

Similar question here as for handleEnter.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Similar answer here as for handleEnter.

Roy Sutton added 3 commits November 16, 2017 15:30
Enact-DCO-1.0-Signed-off-by: Roy Sutton roy.sutton@lge.com
Enact-DCO-1.0-Signed-off-by: Roy Sutton roy.sutton@lge.com
Enact-DCO-1.0-Signed-off-by: Roy Sutton roy.sutton@lge.com
@aarontam aarontam merged commit 9f96386 into release/1.x Nov 16, 2017
@aarontam aarontam deleted the feature/ENYO-4811-roysutton branch November 16, 2017 21:44
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants