-
Notifications
You must be signed in to change notification settings - Fork 2k
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
Update signup goals page skip to dashboard set site_intent to build #72883
Update signup goals page skip to dashboard set site_intent to build #72883
Conversation
Here is how your PR affects size of JS and CSS bundles shipped to the user's browser: App Entrypoints (~56 bytes added 📈 [gzipped])
Common code that is always downloaded and parsed every time the app is loaded, no matter which route is used. Sections (~143 bytes added 📈 [gzipped])
Sections contain code specific for a given set of routes. Is downloaded and parsed only when a particular route is navigated to. Async-loaded Components (~46 bytes added 📈 [gzipped])
React components that are loaded lazily, when a certain part of UI is displayed for the first time. Legend What is parsed and gzip size?Parsed Size: Uncompressed size of the JS and CSS files. This much code needs to be parsed and stored in memory. Generated by performance advisor bot at iscalypsofastyet.com. |
Testing
|
TestingRequirements
Browsers
|
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 tests well on my end, minus the other issue tracked elsewhere that shouldnt block this PR. #72872
// If user clicks "Skip to Dashboard" on goals step, | ||
// Default site_intent to "build" | ||
const updatedSiteIntent = intent ? intent : SiteIntent.Build; |
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.
Note this isnt specifically tied to this dashboard button on the goals step, so im curious if there are any other areas this change could potentially bleed into?
That said, testing around and escaping out of other flows early I see the intent the same as expected. So it seems to be looking good in my testing.
|
||
// If user clicks "Skip to Dashboard" on goals step, | ||
// Default site_intent to "build" | ||
const updatedSiteIntent = intent ? intent : SiteIntent.Build; |
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.
Since we're setting a default value for any flow with some falsey value for intent
, would we inadvertently enable launchpad for situations where it's undesired?
I can't think of anything off the top of my head, but I suppose, if we wanted to be safer, we could only set default values for general onboarding
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 left one comment. +1 from me when we decide how we want to approach the concern
@@ -520,6 +523,7 @@ const siteSetupFlow: Flow = { | |||
|
|||
case 'goals': | |||
// Skip to dashboard must have been pressed | |||
setIntent( SiteIntent.Build ); |
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.
Sets site_intent to build
in redux store if user clicks "Skip to dashboard"
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.
Im not understanding the need for the other changes, but this seems like the main thing we need 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.
Yes this is the main change, but I needed to add the other changes in order to get the latest site_intent value.
@@ -191,7 +194,7 @@ const siteSetupFlow: Flow = { | |||
navigate( 'processing' ); | |||
|
|||
// Clean-up the store so that if onboard for new site will be launched it will be launched with no preselected values | |||
resetOnboardStoreWithSkipFlags( [ 'skipPendingAction' ] ); | |||
resetOnboardStoreWithSkipFlags( [ 'skipPendingAction', 'skipIntent' ] ); |
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.
Added skipIntent
flag to prevent the site intent from being deleted before its used in the setPendingAction function above.
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 dont see this reset being called in many other places. So it seems like we are adding skipIntent
to the main case 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.
Yes im adding it here to ensure Im still able to retrieve the site intent value from redux inside the exitFlow
pendingActions code.
Without adding this and modifying redux, I noticed that site intent value was always an empty string when I used the getIntent
selector.
@@ -294,6 +294,9 @@ const intent: Reducer< string, OnboardAction > = ( state = '', action ) => { | |||
if ( action.type === 'SET_INTENT' ) { | |||
return action.intent; | |||
} | |||
if ( action.type === 'RESET_ONBOARD_STORE' && action?.skipFlags?.includes( 'skipIntent' ) ) { |
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.
If we reset the onboard store and include the skipIntent
flag, then we don't want to delete the site_intent state value.
✅ Still tests well after the changes |
|
||
const siteIntent = getIntent(); | ||
const siteId = site?.ID; | ||
const pendingActions = [ | ||
setIntentOnSite( siteSlug, intent ), | ||
setIntentOnSite( siteSlug, siteIntent ), |
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.
why cant we use the regular intent
here (and below)? Is there a reason we need to have both:
const intent = useSelect( ( select ) => select( ONBOARD_STORE ).getIntent() );
const { getIntent } = useSelect( ( select ) => select( ONBOARD_STORE ) );
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.
Im not able to get the correct value from using the existing intent
variable. It appears as an empty string.
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 was going to ask the same question. Any thoughts on why? I assume it may a JS timing issue related to how and when pendingAction is invoked? Like in one case, you're getting the value of intent NOW as you set up the function (essentially acts as a closure and stores the current value), and in the other, your fetching site intent later, when the method itself is fired.
I will say it seems odd in this file to be fetching intent here twice via two different methods, in two different places.
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 one other thing I'm puzzle by here is that before this PR, we WERE using the first/original intent value. Does that mean that code was not working as expected?
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'm a bit concerned about whether this change (since it clearly does change the behavior and possible value of intent) will have unexpected impact on other existing flows beyond what we're wanting to do just for ours.
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.
Reviewed this @agrullon95 and just did some extensive testing of other scenarios and flows to confirm I'm not seeing any issues.
@@ -191,7 +194,7 @@ const siteSetupFlow: Flow = { | |||
navigate( 'processing' ); | |||
|
|||
// Clean-up the store so that if onboard for new site will be launched it will be launched with no preselected values | |||
resetOnboardStoreWithSkipFlags( [ 'skipPendingAction' ] ); | |||
resetOnboardStoreWithSkipFlags( [ 'skipPendingAction', 'skipIntent' ] ); |
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 dont see this reset being called in many other places. So it seems like we are adding skipIntent
to the main case 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.
Behavior tests well on my end 👍
To be safe and communicative here, would you mind writing a P2 about this and crossposting for dotcom and related teams? essentially that we are making this "skip" from this goals page default to build
, similar to how "other" flow defaults to build
? Mostly as a heads up, but also to double check for any concerns with this we may have missed?
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 tests as expected. I have some concerns that these code changes could plausibly impact how intent is set in a range of circumstances. I reviewed with @agrullon95 and I tested both the intended scenario (Skip to Dashboard) but also a wide mix of other flows and scenarios, and everything tests as expected.
In another comment @Addison-Stavlo mentioned maybe posting about this. Not sure if it's worth flagging one of the people who worked on the site-setup-flow file to confirm they're good with it too?
All that said, given all the checks and testing, I'm also approving now.
@edanzer - I added a link to the P2 in the description where I gave other teams a heads-up about these changes |
Testing/Review instructions
Test: short
Review: short
Proposed Changes
Currently, users that click the
Skip to dashboard
link on the top right-hand corner of the Goals onboarding step will be navigated to the home screen with the following site options:site_intent
= ""launchpad_screen
= falseThe changes in this PR will set the
site_intent
site option tobuild
if the user clicksSkip to dashboard
on the Goals page. This will also enable the launchpad and set thelaunchpad_screen
site option tofull
before the user is navigated to the home screen.P2 post to give heads up: paYE8P-2yP-p2
Goals step:
Testing Instructions
< Switch Site
on the Calypso sidebar and then clickAdd a new site
)Skip to dashboard
. Thesite_intent
andlaunchpad_screen
values should be updated. The home screen should redirect you to the launchpad screen (There may be a bug that requires multiple refreshes before you redirected - )Write & Publish
to verify the correctsite_intent
value is setPre-merge Checklist
Related to #72870