-
Notifications
You must be signed in to change notification settings - Fork 58
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
UIP-1802 CSS Transition Timeout/Warning #55
UIP-1802 CSS Transition Timeout/Warning #55
Conversation
UIP-2052 Release over_react 1.7.0
RavenNumber of Findings: 0 |
Codecov Report
@@ Coverage Diff @@
## release_1.7.0 #55 +/- ##
=================================================
+ Coverage 97.71% 97.72% +0.01%
=================================================
Files 28 28
Lines 1352 1356 +4
=================================================
+ Hits 1321 1325 +4
Misses 31 31 Continue to review full report at Codecov.
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just a few pieces of feedback
@@ -123,6 +123,9 @@ abstract class AbstractTransitionComponent<T extends AbstractTransitionProps, S | |||
/// Whether the Element returned by [getTransitionDomNode] will have a transition event. | |||
bool get hasTransition => true; | |||
|
|||
/// The duration that can elapse before a transition timeout occurs. | |||
Duration get transitionTimeout => const Duration(seconds: 15); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should have a discussion around the default value for this.
@aaronlademann-wf @greglittlefield-wf @clairesarsam-wf @joelleibow-wf
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd say make this a prop so that it's configurable, and default it to something much smaller, like 1s, so that consumers see the warning right away.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I feel like a getter is better for this, similar to hasTransition
. That way consumers have the ability to either proxy it with a prop or have a custom implementation.
1s sounds good to me tho.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, the only reason I said prop is that it would be easier to override. Good point, I'm fine leaving it as a getter.
@@ -184,7 +187,12 @@ abstract class AbstractTransitionComponent<T extends AbstractTransitionProps, S | |||
skipCount = 0; | |||
} | |||
|
|||
var timer = new Timer(transitionTimeout, () { | |||
assert(ValidationUtil.warn("A transition timeout has occurred.")); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
#nit Should use single quotes '
vs "
@@ -184,7 +187,12 @@ abstract class AbstractTransitionComponent<T extends AbstractTransitionProps, S | |||
skipCount = 0; | |||
} | |||
|
|||
var timer = new Timer(transitionTimeout, () { | |||
assert(ValidationUtil.warn("A transition timeout has occurred.")); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This should be a more informative message. Something like: 'The amount of transitions expected to complete have not completed. Something is most likely wrong.' The wording isn't great but something that get across the point that we are expecting some amount of transitions and they have not fired.
|
||
TransitionerComponent transitioner = getDartComponent(renderedInstance); | ||
|
||
transitioner.hide(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You should add a expect
before and after this that verifies that the state.transtionPhase
is TransitionPhase.SHOWN
.
var timer = new Timer(transitionTimeout, () { | ||
assert(ValidationUtil.warn( | ||
'The number of transitions expected to complete have not completed. Something is most likely wrong.' | ||
)); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Something else that I was thinking about. Should we still call complete
if the timer completes? I could go either way, was just wondering what the desired behavior is.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Mm, yes, we should, in order to account for when the warning isn't caught by the time this is deployed
@@ -444,6 +471,7 @@ class TransitionerComponent extends AbstractTransitionComponent<TransitionerProp | |||
..addProps(super.getDefaultProps()) | |||
..hasTransition = true | |||
..initiallyShown = true | |||
..transitionTimeout = const Duration(seconds: 15) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This should be updated to match the default in AbstractTransitionComponent
+1 |
Merging.+10 |
RM +1 verified dependencies |
…assist Remove prop navigation assist
Ultimate problem:
When creating components that utilize the
AbstractTransitionComponent
, it's possible to set transition to a value that something like anOverlayTrigger
doesn't know about, which causes the cleanup of the component to hang.How it was fixed:
transitionTimeout
getter toAbstractTransitionComponent
that can be overridden to adjust the desired timeout duration.Timer
and display a warning after a timeout has occurred.Testing suggestions:
Potential areas of regression: