-
Notifications
You must be signed in to change notification settings - Fork 647
refactor(Transition): improve timeout prop as a object and make optional
#629
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
Conversation
|
Marked as draft because have some questions that appearered after looking at method |
|
Ok, the purpose of this PR deviates from original scope, I'll rename, and adapt to new changes. |
getTimeouts to a pure functiontimeout prop as a object and make optional
| setTimeout(this.nextCallback, 0) | ||
| return | ||
| } | ||
| if (node && this.props.addEndListener && timeout == null) { |
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.
@taion why node check is needed here in onTransitionEnd?
addEndListener check is not enough for this?
Or is here for some historic reasons?
Tests pass if node check is removed from if check.
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 think this is a legacy thing from the conversion to use nodeRef; if there's no associated node, then previously it was impossible to call addEndListener, because the first arg was expected to be the node.
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.
Is there any case when node may be missing?
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.
might be possible if e.g. the transition is rendering a child that's actually not there, maybe?
| setTimeout(this.nextCallback, 0) | ||
| return | ||
| } | ||
| if (node && this.props.addEndListener && timeout == null) { |
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 think this is a legacy thing from the conversion to use nodeRef; if there's no associated node, then previously it was impossible to call addEndListener, because the first arg was expected to be the node.
|
|
||
| if (timeout != null) { | ||
| setTimeout(this.nextCallback, timeout) | ||
| this.props.addEndListener(maybeNode, maybeNextCallback) |
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 is not equivalent to the original code. previously, if:
nodewas definedaddEndListenerwas definedtimeoutwas defined
then we would call addEndListener and we would call setTimeout with this.nextCallback.
in this revision, there's no way for both addEndListener and setTimeout to get called
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.
Is this the right behaviour for both of them to call nextCallback?
Does setNextCallback appeared in codebase because of this, to call callback only once?
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 think the idea is that, if there's a timeout and an end listener, that the first one that triggers will "win"
…ional Purpose of #464 was to make timeout optional and default to 0 if `addEndListener` prop is missing, but propType was still marked as required Also removed unused class `SimpleSet`
Purpose of #464 was to make timeout optional and default to 0
if
addEndListenerprop is missing, but propType was still marked asrequired
Also removed unused class
SimpleSet