-
Notifications
You must be signed in to change notification settings - Fork 296
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
Enhancement/4925 survey timeouts #5003
Conversation
This comment was marked as resolved.
This comment was marked as resolved.
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 largely looks good, just a few questions and small comments. I think after that this can get merged 👍🏻
I tested it locally and it worked well 👍🏻
<SurveyViewTrigger triggerID="view_dashboard" ttl={ 3600 } /> | ||
<SurveyViewTrigger | ||
triggerID="view_dashboard" | ||
ttl={ DAY_IN_SECONDS } |
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.
❤️
array( | ||
'data' => array( | ||
'slug' => 'bar', | ||
'timeout' => 100, // phpcs:ignore WordPressVIPMinimum.Performance.RemoteRequestTimeout.timeout_timeout |
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.
Hah, is this getting triggering incorrectly? Maybe we should add a comment highlighting this, in case someone sees this later and doesn't know why we're (legitimately) disabling this rule here.
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.
Yep. Added a comment .
); | ||
|
||
if ( false === cacheHit ) { | ||
if ( ! isTimedOut && ! isTimingOut ) { |
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.
Should these be checks for isTimedOut === false
rather than ! isTimedOut
? Because isTimedOut
could be undefined
… do we want this to behave the same way if it's false
and undefined
?
if ( ! isTimedOut && ! isTimingOut ) { | |
if ( ! isTimedOut && ! isTimingOut ) { |
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.
Those variables are always resolved by the time we get them. Added a comment that explains it.
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.
Ah, awesome, thanks! I think in that case too it's fine to be less explicit with the checks as anyone reading this for prior art will see the comment and know why we're doing a false-y rather than === false
check. 👍🏻
Co-authored-by: Matthew Riley MacPherson <hi@tofumatt.com>
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.
Awesome, thanks for the comments. Works great when tested locally 🚢
); | ||
|
||
if ( false === cacheHit ) { | ||
if ( ! isTimedOut && ! isTimingOut ) { |
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.
Ah, awesome, thanks! I think in that case too it's fine to be less explicit with the checks as anyone reading this for prior art will see the comment and know why we're doing a false-y rather than === false
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.
@eugene-manuilov @tofumatt One post-merge question here.
const isTimedOut = useSelect( ( select ) => | ||
select( CORE_USER ).isSurveyTimedOut( triggerID ) | ||
); | ||
const isTimingOut = useSelect( ( select ) => | ||
select( CORE_USER ).isTimingOutSurvey( triggerID ) | ||
); | ||
|
||
const { triggerSurvey } = useDispatch( CORE_USER ); | ||
|
||
useMount( () => { | ||
if ( usingProxy ) { | ||
const shouldTriggerSurvey = isTimedOut === false && isTimingOut === false; | ||
|
||
useEffect( () => { | ||
if ( shouldTriggerSurvey && usingProxy ) { | ||
triggerSurvey( triggerID, { ttl } ); | ||
} | ||
} ); | ||
}, [ shouldTriggerSurvey, usingProxy, triggerSurvey, triggerID, ttl ] ); |
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.
Why is all this needed? It looks like the triggerSurvey
action already includes these checks and also ensures the API-based bits are resolved. Why duplicate these conditions in here?
I'm not sure why it's needed, and it makes me slightly worried relying on useEffect
instead of useMount
, since this really should only happen 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.
Ah, that's a fair point. With triggerSurvey
making sure everything is resolved this isn't needed, but I tend to think about building components like this to protect against unresolved selectors… in this case all of the selectors themselves could return undefined
so waiting on them to fulfill like this seemed best.
I don't think this would ever "trigger twice" unintentionally, but in this case replacing it with the action on-mount with a commend saying "The action waits for all relevant selectors to resolve so this is fine to call." would work.
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.
@tofumatt I'll leave it to you and @eugene-manuilov to make a decision on this, but my thinking is that the additional code here is somewhat of a duplicate since the action is already resilient enough to "make sure it works", plus the point about useEffect
theoretically being more error-prone to calling the action multiple times - while I agree in that I cannot see a point where this happens using the current logic, it feels more error-prone than using useMount
.
If you still feel the current approach is more resilient, we can leave it, but if you agree, please open a follow-up PR to address this.
Summary
Addresses issue:
view_dashboard
surveys more reliable and extend it #4925Relevant technical choices
PR Author Checklist
Do not alter or remove anything below. The following sections will be managed by moderators only.
Code Reviewer Checklist
Merge Reviewer Checklist