-
Notifications
You must be signed in to change notification settings - Fork 4.3k
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
withNotices: Ensure that the callback props are stable. #29491
withNotices: Ensure that the callback props are stable. #29491
Conversation
I tested and it looks good to me, but I'd like to get other opinions. @stokesman would you be able to take a look too? Thanks in advance :-) |
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've reproduced the issue with the Jetpack podcast player block and verified that these changes resolve that issue. So I don't see any reason not to 🚢
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.
Tested and it works as expected. ✅ too. 👍
Tested and it works as expected. Merging since Paul doesn't have access to merge yet. |
The refactor of withNotices in WordPress#28676 introduced a bug where the functions within `noticeOperations` were changing on every render. That meant that if they were present in the dependency array of a useEffect, then the effect would trigger causing an infinite loop. This was partially fixed with WordPress#29491, but there are other instances where the noticeOperations object itself is being listed as a dependency, and so the problem persists. As suggested by @stokesman WordPress#29491 (comment) this change memoizes the whole object.
The refactor of withNotices in #28676 introduced a bug where the functions within `noticeOperations` were changing on every render. That meant that if they were present in the dependency array of a useEffect, then the effect would trigger causing an infinite loop. This was partially fixed with #29491, but there are other instances where the noticeOperations object itself is being listed as a dependency, and so the problem persists. As suggested by @stokesman #29491 (comment) this change memoizes the whole object.
The refactor of withNotices in #28676 introduced a bug where the functions within `noticeOperations` were changing on every render. That meant that if they were present in the dependency array of a useEffect, then the effect would trigger causing an infinite loop. This was partially fixed with #29491, but there are other instances where the noticeOperations object itself is being listed as a dependency, and so the problem persists. As suggested by @stokesman #29491 (comment) this change memoizes the whole object.
Description
In #28676
withNotices
was refactored to as a functional component. In the Jetpack podcast player block, the functions supplied as props were being used within a function calling the API. This essentially meant they became a dependency of theuseEffect
hook and caused the API call to happen in a loop.If these are used in hooks elsewhere it would also cause a loop as the function references change on each render.
This change constructs each of the
noticeOperations
usinguseCallback
to memoize them and prevent any unnecessary rerenders.How has this been tested?
This has been tested in conjunction with the latest release of Jetpack. The bug can be seen by inserting a podcast block into a post and setting the podcast feed URL. With this PR the loop is removed.
Screenshots
Types of changes
Bug fix - It makes
withNotices
behave more as it did before the refactor.Checklist: