-
Notifications
You must be signed in to change notification settings - Fork 798
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
Social: Remove the flow to update broken connections directly from the editor. #35343
Social: Remove the flow to update broken connections directly from the editor. #35343
Conversation
Are you an Automattician? Please test your changes on all WordPress.com environments to help mitigate accidental explosions.
Interested in more tips and information?
|
Thank you for your PR! When contributing to Jetpack, we have a few suggestions that can help us test and review your patch:
This comment will be updated as you work on your PR and make changes. If you think that some of those checks are not needed for your PR, please explain why you think so. Thanks for cooperation 🤖 The e2e test report can be found here. Please note that it can take a few minutes after the e2e tests checks are complete for the report to be available. Once your PR is ready for review, check one last time that all required checks appearing at the bottom of this PR are passing or skipped. |
ffaa071
to
e87efb8
Compare
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 working well for me, but I wonder if we should get rid of more code!
|
||
return null; | ||
} | ||
|
||
renderNonRefreshableConnections() { |
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 might never be used as all connections are being returned as refreshable (as long as the user is an admin). It also does the same as above and renders the message received from the server, which I don't think we want to happen, because we'll end up with two notices about broken connections.
Should we get rid of this too?
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 have done that, but this leaves <PublicizeConnectionVerify>
as a component that returns null in the render function. It's calling the connection-test-results
in componentDidMount
, but I think there is some scope for refactoring this component and moving the necessary code into the PublicizePanel
. Should we do that in a follow-up? Or is there a simple way to do it now?
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.
Hmmm, good point. It's only used here, so, like you say, maybe we could dispatch the request in a useEffect
instead, and get rid of this component altogether.
I think it is ok to have this return null
, so we could merge this to make sure it makes the release, and then refactor it.
e87efb8
to
1d4d9b9
Compare
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.
Let's refactor this, to something like a custom hook, in a follow-up change
Proposed changes:
Other information:
Jetpack product discussion
Does this pull request change what data or activity we track or use?
Testing instructions: