-
Notifications
You must be signed in to change notification settings - Fork 796
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
Jetpack: Extend disconnection dialog component to handle multiple steps and accept more props #21048
Jetpack: Extend disconnection dialog component to handle multiple steps and accept more props #21048
Conversation
… multiple steps and accept more props
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.
Here are some suggested test cases for this PR.
Connection
- In-place connection with free plan
- In-place connection with paid plan
- In-place connection with product purchase
- Classic connection. Use Safari, or set a constant
JETPACK_SHOULD_NOT_USE_CONNECTION_IFRAME
to true - Disconnect/reconnect connection
- Secondary user connection
- Connection on multisite
Verify that the changes are compatible with the plugins that use the connection package.
- WooCommerce Payments
- Jetpack Boost
- Previous versions of Jetpack
If you think that suggestions should be improved please edit the configuration file here. You can also modify/add test-suites to be used in the configuration file.
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 (other than "Required review") appearing at the bottom of this PR are passing or skipped. Jetpack plugin:
Backup plugin:
Boost plugin:
|
…nt to show connected plugins and Jetpack benefit information
Caution: This PR has changes that must be merged to WordPress.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.
Hi Josh,
Thank you so much for working on this.
Some initial thoughts:
- I think we can create a new
DisconnectSurvey
component and make use of that inDisconnectDialog
. - I'd suggest the above for
ConnectedPlugins
. Aka introduce a new RNA component that will render the connected plugins (in the same spirit you createdDisconnectCard
) outside of theDisconnectDialog
context
Caveats! What we need to pay extra attention about the DisconnectDialog
component is that even though we make the REST API call to disconnect (and get a successful response) we need to be careful not to update the state immediately (or call the onDisconnected
cb) because if we did that the component itself would not render anymore.
Therefore, informing the state and calling onDisconnected
would happen upon clicking the "Back to Wordpress" button. This was carefully designed to be the only way to close the modal, so now we need to ensure that any button that closes / completes the survey will do the same.
For this reason, I'd propose the suggested DisconnectSurvey
component to accept callbacks onSubmit
and onDismiss
in which we will make sure to pass the disconnect handler.
Let me know your thoughts!
Thanks for the feedback @fgiannar ! |
Hi Josh, thanks for the PR! What exactly is the When this disconnect dialog is used in the Plugins page, upon plugin deactivation, we don't need to make the API request to disconnect the site because it will get disconnected during the plugin deactivation hook. Do you think it's possible to add a prop there to skip the actual disconnection in this case? |
Thanks for the feedback @leogermani
This is the decorative element that shows on the 2nd and 4th steps of the disconnect flow, something like this: I do think this has some potential for re-use, I've broken it out into a separate component.
Sure thing, I have a |
…nnect-dialog-component
…m:Automattic/jetpack into update/extend-disconnect-dialog-component
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 tests well for me, I think it's mostly ready to merge at this point. I'll approve. I have a remark, but that's something that can be addressed in a follow-up PR, so you don't have to go through the whole dependency update again :)
I should note that I did not review the accessibility of the modal / survey steps; I am not very knowledgeable on that topic. Is that something you've tested on your end, try to go through the flow with the keyboard for example?
Also if note, I got a 404 on the survey API endpoint at the end of the survey once, but could not reproduce afterwards.
unset( $active_plugins_using_connection['jetpack'] ); | ||
$this->load_view( 'admin/deactivation-dialog.php', $active_plugins_using_connection ); | ||
public function jetpack_plugin_portal_containers() { | ||
$this->load_view( 'admin/jetpack-plugin-portal-containers.php' ); |
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.
At this point and as I'm looking at this again, I wonder if it's worth loading an extra file vs. just adding the 2 div containers right here in the function. If there was more in that template file, extracting would be worth it, but here I'm not sure. What do you think?
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.
Hmm 🤔
I think I could go either way. I tend towards a preference to not output HTML from functions where possible, seems like a nice separation of logic vs output. But you are correct in that there's not much to output in the template file. Would the benefit of including the HTML inline here be the elimination of an extra file?
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.
Would the benefit of including the HTML inline here be the elimination of an extra file?
Yeah, exactly. The more I look at it the more I think that extra file may be a bit overkill. That said, I'm not feeling strongly about this, so happy to merge this as it is. I'll approve this PR again and let you decide. 👍
Co-authored-by: Jeremy Herve <jeremy@jeremy.hu>
@jeherve - I have not tested for this specifically. I'll make a note/ task to follow up and make any related updates. |
Great news! One last step: head over to your WordPress.com diff, D68232-code, and commit it. Thank you! |
r235765-wpcom |
* master: (22 commits) Update storybook monorepo to v6.4.0 (#21897) Refresh the site's modules and settings after successful product activation (#21886) Plugin Install: Bump MC stat on success or fail. (#21893) Nav Unification: Use correct user capability for the Inbox menu item (#21882) Jetpack: Extend disconnection dialog component to handle multiple steps and accept more props (#21048) Disable CSSTidy property shorthand optimization in the editor or headstart (#21891) Connection UI: Update Composer instructions in README.md (#21890) Partner Compatibility: Adding a unique connection screen for customers who receive a coupon from a Jetpack partner (#21813) Search package: move search dashboard to package - the base (#21865) JITM: wrap CTA below text on small viewports (#21688) Licensing JS Package – fix icon positioning and width (#21878) JITM: new JS and CSS builder (#21874) Support site_intent for `/me/sites` endpoint (#21880) Don't render Critical CSS while generating CritCSS. (#21879) ConnectScreen: make button full width on small screens (#21683) Improve the copy of the license activation banner (#21876) Rename Webpack-built files back from `.min.js` and remove hashes (#21748) Search: Migrate more helper classes to package (#21751) Search: migrate/add search rest API (#21584) Add initial state to the connection package (#21864) ...
Did a pass over _inc/client/components looking for things that weren't used anywhere, and found a bunch: * components/data/query-connect-url - Last use removed in #8014 * components/data/query-connection-status - Last use removed in 62e9ab0 * components/data/query-modules - Last use removed in bfc40ad * components/data/query-plugin-updates - Last use removed in #17003 * components/data/query-site-products - Last use removed in #21594 * components/form/* - Didn't check for last use, too many bits. But it looks like the `formsy-react` package many of these depended on wasn't even installed since #8208. * components/inline-expand - Last use removed in #6550 * components/jetpack-dialogue - Last use removed in #16518 * components/jetpack-logo - Last use removed in #20148 * components/jetpack-termination-dialog - Last use removed in #21048 * components/module-settings/index.jsx - Last use removed in #10644 * components/module-settings/inline-module-toggle.jsx - Last use removed in #12118 * components/screen-reader-text - Last use removed in #18843 * components/settings - Last use removed in 26315e1, I think * components/tags-input - Last use removed in #11772 Then there were a few more that were only used from some of the above: * components/data/query-connected-plugins * components/module-settings/form-components.jsx * components/multiple-choice-question * components/setting-toggle
Did a pass over _inc/client/components looking for things that weren't used anywhere, and found a bunch: * components/data/query-connect-url - Last use removed in #8014 * components/data/query-connection-status - Last use removed in 62e9ab0 * components/data/query-modules - Last use removed in bfc40ad * components/data/query-plugin-updates - Last use removed in #17003 * components/data/query-site-products - Last use removed in #21594 * components/form/* - Didn't check for last use, too many bits. But it looks like the `formsy-react` package many of these depended on wasn't even installed since #8208. * components/inline-expand - Last use removed in #6550 * components/jetpack-dialogue - Last use removed in #16518 * components/jetpack-logo - Last use removed in #20148 * components/jetpack-termination-dialog - Last use removed in #21048 * components/module-settings/index.jsx - Last use removed in #10644 * components/module-settings/inline-module-toggle.jsx - Last use removed in #12118 * components/screen-reader-text - Last use removed in #18843 * components/settings - Last use removed in 26315e1, I think * components/tags-input - Last use removed in #11772 Then there were a few more that were only used from some of the above: * components/data/query-connected-plugins * components/module-settings/form-components.jsx * components/multiple-choice-question * components/setting-toggle Co-authored-by: Brandon Kraft <public@brandonkraft.com>
Notable changes: * Remove `Jetpack_User_Agent_Info::is_OperaMobile()`. #16434 removed the jetpack-device-detect function this was calling in October 2021, but missed this caller. * Remove `jetpack_server_sandbox()` and `jetpack_server_sandbox_request_parameters()`. Due to a wrong namespace in #21128, they'd have thrown fatals since October 2021. * Use `$skin` instead of `$upgrader->skin`, it's the same object but not typed as a parent class. Should be no change to functionality. * Add some missing methods to `WPCOM_JSON_API`. * Add some missing abstract methods to SAL_Site, and implement in Jetpack_Site. * Fix `SAL_Token::is_global()`. * Remove `views/admin/deactivation-dialog.php`, unused since #21048 in November 2021. * Add `@phan-var-force` in a lot of "template" files. I'm not entirely happy with this, it pollutes the global scope for any subsequent files processed, but short of writing a Phan plugin that somehow adjusts the scope for only the file I can't find a better idea.
Notable changes: * Remove `Jetpack_User_Agent_Info::is_OperaMobile()`. #16434 removed the jetpack-device-detect function this was calling in October 2021, but missed this caller. * Remove `jetpack_server_sandbox()` and `jetpack_server_sandbox_request_parameters()`. Due to a wrong namespace in #21128, they'd have thrown fatals since October 2021. * Use `$skin` instead of `$upgrader->skin`, it's the same object but not typed as a parent class. Should be no change to functionality. * Add some missing methods to `WPCOM_JSON_API`. * Add some missing abstract methods to SAL_Site, and implement in Jetpack_Site. * Fix `SAL_Token::is_global()`. * Remove `views/admin/deactivation-dialog.php`, unused since #21048 in November 2021. * Add `@phan-var-force` in a lot of "template" files. I'm not entirely happy with this, it pollutes the global scope for any subsequent files processed, but short of writing a Phan plugin that somehow adjusts the scope for only the file I can't find a better idea.
This PR extends the disconnect dialog component so that it can show more information before disconnecting and then provide a feedback survey following disconnection. The dialog prop set is expanded with the intent of re-using the component in different contexts.
Changes proposed in this Pull Request:
Update the disconnect dialog component to have a multi-step disconnect flow:
1 : Disconnect screen - show optional information passed via props and allow user to disconnect
2: Disconnect confirmation - shows following successful disconnection
3: Optional Feedback survey - allow user to provide optional feedback after disconnecting
4: Thank you step - shows after the user elects to submit feedback
Add several additional props to make the disconnect modal more flexible in multiple contexts
Notably, props added include
connectedPlugins
that will show a list of other plugins that are using the Jetpack connection, anddisconnectComponent
which allows for a component to be passed that will render on the first screen of the disconnect flow.Jetpack product discussion
pbNhbs-1n2-p2
p9dueE-3NP-p2
Does this pull request change what data or activity we track or use?
This PR allows the user to submit an optional feedback survey. The survey response is connected to the user's ID.
Analytics events are recorded for how a user interacts with the disconnect flow ( opening the flow, what steps are viewed, submitting the survey ) - see a full list of these events at the bottom of the test plan on this PR.
Related:
#21421 #20914
Testing instructions:
Check out this branch on your Jetpack development environment
The updates in this PR are most readily observed when disconnecting via the Jetpack Backups plugin, make sure you have the Jetpack Backups plugin installed and that Jetpack is connected.
If you have not already, build the scripts for the Jetpack Backup plugin with
jetpack build
In the wp-admin, navigate to the admin page for the Jetpack Backup plugin and click the "Disconnect" link in the Connection section
You should be presented with the first step of the disconnect flow, which will present a general warning message about disconnecting Jetpack:
Click on "Disconnect" to disconnect the site. The button should show "Disconnecting" while disconnection is in progress.
After a successful disconnect, you will see the disconnect confirmation screen, which will show a "Back to my website" button. Clicking "Back to my website" will exit the disconnect flow and you should see the Jetpack connection screen for the Jetpack Backups plugin.
This PR does include changes to show an additional survey step and a thank you step as part of the disconnection flow. However, it relies on the consumer of the JS connection package to provide some of the information required to collect the survey. Please see the test plan for Backup: provide additional disconnect info in backup plugin #21421 to test the full disconnection flow, including the survey and thank you screens.
This PR collects analytics events, but it does not have the correct scripts loaded to send them to tracks. Check that the
window._tkq
array contains events related to the disconnect flow. If you complete the test plan, you should see the following event names inwindow.tkq
when on the "Jetpack Disconnected" step of the flow:jetpack_disconnect_dialog_open
jetpack_disconnect_dialog_step
with propstep
ofdisconnect
jetpack_disconnect_dialog_step
with propstep
ofdisconnect_confirm
Additional events that are collected in subsequent steps of the flow ( see test plan for #21421 ) are:
jetpack_disconnect_dialog_step
with propstep
ofsurvey
jetpack_disconnect_survey_submit
jetpack_disconnect_dialog_step
with propstep
ofthank_you