-
Notifications
You must be signed in to change notification settings - Fork 801
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: Refresh store on Publicize module toggle via 1 call #34142
Social: Refresh store on Publicize module toggle via 1 call #34142
Conversation
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. 🔴 Action required: Please add missing changelog entries for the following projects: Use the Jetpack CLI tool to generate changelog entries by running the following command: 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. Jetpack plugin: The Jetpack plugin has different release cadences depending on the platform:
If you have any questions about the release process, please ask in the #jetpack-releases channel on Slack. Social plugin:
If you have any questions about the release process, please ask in the #jetpack-releases channel on Slack. |
Are you an Automattician? Please test your changes on all WordPress.com environments to help mitigate accidental explosions.
Interested in more tips and information?
|
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.
Looks good. I need to give it a proper test, but I've left a few comments
useEffect( () => { | ||
if ( | ||
isModuleEnabled && | ||
isUpdatingJetpackSettings && |
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 this be:
isUpdatingJetpackSettings && | |
! isUpdatingJetpackSettings && |
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 it makes sense to update the store while the main module is turning on, this way it will be refreshed already when the toggles appear, reducing the page jank
) { | ||
refreshJetpackSocialSettings(); | ||
} | ||
} ); |
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 hasn't got a dependency array, which will mean that it runs on every render. I think putting it a useEffect means that it runs after the render rather than before. Is that what's intended?
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 useEffect
may also be unnecessary.
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.
@@ -90,10 +102,10 @@ const Admin = () => { | |||
<InstagramNotice onUpgrade={ onUpgradeToggle } /> | |||
<SocialModuleToggle /> | |||
{ ! isUpdatingJetpackSettings && isModuleEnabled && isAutoConversionAvailable && ( | |||
<AutoConversionToggle shouldRefresh /> | |||
<AutoConversionToggle /> |
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 we still render it but disable it if the state is updating? It might mean that there's less page jank. I don't know if there's a busy/loading state that we can use with the toggles, but that would be great.
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.
There is no page jank, the store has an isUpdating flag for each which disables the toggle while updating. Is that what you ask about?
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.
Not quite, I was thinking that there's an ! isUpdatingJetpackSettings
check, so if isUpdatingJetpackSettings
we won't rending the toggle at all.
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.
Oh I see what you mean. It's working this way on Jetpack Settings that's what I mimicked, but I can make that be there even with Publicize off if you think that's better.
* @param {object} props.children - The children to render. | ||
* @returns { object } The refreshJetpackSocialSettings function. | ||
*/ | ||
export default function RefreshJetpackSocialSettingsWrapper( { shouldRefresh, children } ) { |
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 wonder if this file should be in a folder named refresh-social-settings
{ shouldShowChildElements && hasSocialImageGenerator && ( | ||
<SocialImageGeneratorSection /> | ||
) } | ||
<RefreshJetpackSocialSettingsWrapper |
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.
Are we using this component here so we can encapsulate the useEffect
because this is a class component?
That's probably fine, but it might be worth checking that we don't want to do something like handle it with a lifecycle method in 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.
useEffect
is not even needed for this and thus a lifecycle method may be a good place for 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.
Yeah, and also useDispatch
. I added the useEffect to fix an issue earlier where the inner component was updated while the parent was changing, but it seems that's already fixed and it might not be needed. I think we still need the component to be able to dispatch the store function, or we need to wrap publicize.jsx into another HOC component
projects/js-packages/publicize-components/src/components/refresh-jetpack-settings/index.js
Outdated
Show resolved
Hide 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.
Looks good. Couple of thoughts, as always! Sorry...
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.
It looks good now.
2b51295
into
refactor/social-register-feature-settings
* Add the new settings object + tests * Update initial states + previous usages * Update UI + store functions * changelog * Fix versions * Add control for fetching both options together * Social: Remove deprecated feature files (#34114) * Remove unneeded files * changelog * Social: Refresh store on Publicize module toggle via 1 call (#34142) * Remove previous refresh functionality * Add wrapper to refresh settings in class component on Jetpack Settings * Refresh on social admin page on module toggle change * Remove useEffect * Run useEffect only once on module update * Show toggles instantly on change + only refresh ones on page lifetime * Update ref logic * Rename structure * Fixup versions * Fix template issue, and make sure it's migrated * fix tests * Test fix * Fix auto-conversion migration logic + add test * Add auto-conversion sync option * changelog * Update versions * Fix versions
This change updates how we refresh our options on the Publicize module change, and will use the common api fetch, so we can decrease the number of API calls.
Proposed changes:
Other information:
Jetpack product discussion
https://github.com/orgs/Automattic/projects/733/views/2?pane=issue&itemId=44049666
Does this pull request change what data or activity we track or use?
No.
Testing instructions: