-
Notifications
You must be signed in to change notification settings - Fork 903
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
402 implement site kit setup flow #21978
base: trunk
Are you sure you want to change the base?
Conversation
add stepper to ui library export stepper fix stories args move margin out of the plugin fix story space
add translation to the stepper
Pull Request Test Coverage Report for Build f007acaf20c302eb1fdd48ebcbcc1eb5ef88a8fbWarning: This coverage report may be inaccurate.This pull request's base commit is no longer the HEAD commit of its target branch. This means it includes changes from outside the original pull request, including, potentially, unrelated coverage changes.
Details
💛 - Coveralls |
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.
CR 🏗️
- About the changelogs/label: You put enhancement while I don't think the unreleased should go in there, right? So probably you meant to signal
enhancement
for the UI library one. You can do both, see documentation.
AT ❓
- Getting the following React warning (first run, but already on just not connected):
Warning: Failed prop type: The prop
isComplete
is marked as required inStepper
, but its value isundefined
.
-
The current step svg does not center in the stepper. In the first it is off to the left/bottom? And the rest is off to the right/bottom?
-
No animations? The FTC' vertical stepper has one -- using our ProgressBar that would be fixed
-
Something seems off with the check size, maybe just the outline thing
-
The UI library storybook story is not responding to the inputs
-
The dropdown menu does not show any hover/selection effect
const googleSiteKitConfiguration = get( window, "wpseoScriptData.dashboard.google_site_kit", { | ||
installed: false, | ||
featureActive: false, | ||
active: false, | ||
setup: false, | ||
connected: false, | ||
installUrl: "", | ||
activateUrl: "", | ||
setupUrl: "", | ||
} ); |
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 was a whole point to try to make this dashboard with the eyes of it being standalone/platform agnostic.
Perhaps this widget is special in that it would never be part of standalone due to it being for a WP plugin.
However, that would mean you should invent some way of adding to the Dashboard from outside instead? I get that that is a bit strange to do when we have no clue how that would look like.
But now the dashboard has hidden expectations on the window. I think I'd prefer at least a clear API, even if that is going to change for standalone 🤔 (e.g. use props?)
@@ -106,6 +128,38 @@ public function get_configuration(): array { | |||
)->to_array(), | |||
'endpoints' => $this->endpoints_repository->get_all_endpoints()->to_array(), | |||
'nonce' => $this->nonce_repository->get_rest_nonce(), | |||
'google_site_kit' => $this->get_google_site_kit_configuration(), |
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.
We use camelcase for JS here for the rest.
'google_site_kit' => $this->get_google_site_kit_configuration(), | |
'googleSiteKit' => $this->get_google_site_kit_configuration(), |
* | ||
* @return array<string|bool> | ||
*/ | ||
public function get_google_site_kit_configuration(): array { |
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 feels to me this should really be an 🧅 thing elsewhere. Similar to our editor script data?
And then it can be reused for the integration page.
(sorry to only mention this now)
const [ showGoogleSiteKit, , , , setRemoveGoogleSiteKit ] = useToggleState( true ); | ||
|
||
const handleRemovePermanently = useCallback( ()=>{ | ||
/* eslint-disable-next-line */ | ||
// TODO: Implement the remove permanently functionality. | ||
setRemoveGoogleSiteKit(); | ||
}, [ setRemoveGoogleSiteKit ] ); |
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 feel like this too should get the initial data. Which might be part of the remove permanently scope?
However, it seems strange that you went and implemented this already while it is out of scope. - Due to the local state "Until next visit" is back already when you switch tab/page in the dashboard (e..g. to general and back). Is this what is wanted/expected?
packages/js/src/dashboard/components/google-site-kit-connection-widget.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.
The whole interaction is not controllable from the inputs. It is possible to connect the inputs to the wrapper component. You can take a look at some other stories using updateArgs
, like the Select one?
const linkParams = useSelect( select => select( "@yoast/general" ).selectLinkParams(), [] ); | ||
const learnMorelink = addQueryArgs( "https://yoa.st/google-site-kit-learn-more", linkParams ); |
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 makes the widget be connected to our WordPress integration already
connected, | ||
active, | ||
setup, | ||
installed, |
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.
We usually indicate boolean names with isX
to indicate it is a boolean true/false thing.
const { buttonProps, currentStep, isComplete } = getButtonAndStepperProps( | ||
active, installed, setup, connected, installUrl, activateUrl, setupUrl ); | ||
return <Paper className="yst-@container yst-grow yst-max-w-screen-sm yst-p-8 yst-shadow-md yst-relative"> | ||
<button |
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 could be the tertiary
variant (but then it would be color primary), or maybe it is time to add another variant to the UI library button?
I think this is not good for our focus styles, spacing etc:
In fact, the whole popup/menu thing is something the other widgets will also need.
We could chose to extract something at that point, but might be good to think about it a bit at least?
} ); | ||
const stepRef = useRef( [] ); | ||
|
||
useEffect( () => { |
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.
Shouldn't this calculation happen before rendering instead of after?
E.g. there can be a point where the rendered thing is wrong for a moment in time, potentially looking funky.
Context
Summary
This PR can be summarized in the following changelog entry:
Relevant technical choices:
Test instructions
Test instructions for the acceptance test before the PR gets merged
This PR can be acceptance tested by following these steps:
UI library - Stepper element
Relevant test scenarios
Test instructions for QA when the code is in the RC
QA can test this PR by following these steps:
Impact check
This PR affects the following parts of the plugin, which may require extra testing:
UI changes
Other environments
[shopify-seo]
, added test instructions for Shopify and attached theShopify
label to this PR.Documentation
Quality assurance
Innovation
innovation
label.Fixes Implement Site Kit setup flow without the consent modal