-
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
Improve login redirects and step tracking in stepper #91241
Improve login redirects and step tracking in stepper #91241
Conversation
Jetpack Cloud live (direct link)
Automattic for Agencies live (direct link)
|
Here is how your PR affects size of JS and CSS bundles shipped to the user's browser: App Entrypoints (~588 bytes added 📈 [gzipped])
Common code that is always downloaded and parsed every time the app is loaded, no matter which route is used. Sections (~11655 bytes removed 📉 [gzipped])
Sections contain code specific for a given set of routes. Is downloaded and parsed only when a particular route is navigated to. 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. |
@daledupreez I started adding tests to your change and found a scenario I want to confirm. Should we skip the tracking when the renderStep returns a null content? I implemented this scenario on this commit 433160a |
@daledupreez I committed this temporary change 355cce9 with some ideas to clean up the code based on this change. |
355cce9
to
f07f3e2
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.
I can't tell you how much I appreciate this. Thank you so so much sir. Left a few comments here and there.
client/landing/stepper/declarative-flow/internals/components/step-route/index.tsx
Outdated
Show resolved
Hide resolved
client/landing/stepper/declarative-flow/internals/components/step-route/index.tsx
Outdated
Show resolved
Hide resolved
client/landing/stepper/declarative-flow/internals/components/step-route/index.tsx
Show resolved
Hide resolved
client/landing/stepper/declarative-flow/internals/components/step-route/test/index.tsx
Outdated
Show resolved
Hide resolved
/** | ||
* Does the step require a logged-in user? | ||
*/ | ||
requiresLoggedInUser?: boolean; |
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 should make a new type entirely that requires (requiresLoggedInUser
) and deprecate the existing ones, so people get deprecation warnings from TS and the flows would organically upgrade to the new type.
I do something like that 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.
I intentionally left this as optional for now, mostly because the login requirement is actually flow-specific. So I don't think we should define the login requirement as part of the core step definition. (More on that below.)
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.
You're right. Maybe it should be requiresLoggedInUser?: true
?
const redirectTo = addQueryArgs( location.pathname, { | ||
...( locale && locale !== 'en' ? { locale } : {} ), | ||
...( siteId ? { siteId } : {} ), | ||
...( siteSlug ? { siteSlug } : {} ), | ||
...Object.fromEntries( new URLSearchParams( location.search ).entries() ), | ||
} ); |
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.
100% a nit, but I would spread this into 4 ifs
const redirectTo = addQueryArgs( location.pathname, { | |
...( locale && locale !== 'en' ? { locale } : {} ), | |
...( siteId ? { siteId } : {} ), | |
...( siteSlug ? { siteSlug } : {} ), | |
...Object.fromEntries( new URLSearchParams( location.search ).entries() ), | |
} ); | |
let redirectTo = location.pathname; | |
if ( locale && locale !== 'en' ) { | |
redirectTo = addQueryArgs( location.href, { locale } ); | |
} | |
if ( siteId ) { | |
redirectTo = addQueryArgs( location.href, { siteId } ); | |
} | |
if ( siteSlug ) { | |
redirectTo = addQueryArgs( location.href, { siteSlug } ); | |
} | |
if ( siteSlug ) { | |
redirectTo = addQueryArgs( location.href, { siteSlug } ); | |
} |
And I think if we use location.href
(vs pathname
) we don't need to consider the pre-existing params manually.
client/landing/stepper/declarative-flow/internals/components/step-route/index.tsx
Outdated
Show resolved
Hide resolved
client/landing/stepper/declarative-flow/internals/components/step-route/index.tsx
Outdated
Show resolved
Hide resolved
client/landing/stepper/declarative-flow/internals/components/step-route/test/index.tsx
Outdated
Show resolved
Hide resolved
client/landing/stepper/declarative-flow/internals/components/step-route/index.tsx
Outdated
Show resolved
Hide resolved
client/landing/stepper/declarative-flow/internals/components/step-route/test/index.tsx
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.
I have some feedback from inspection. I'll start some testing shortly.
client/landing/stepper/declarative-flow/internals/components/step-route/test/index.tsx
Outdated
Show resolved
Hide resolved
client/landing/stepper/declarative-flow/internals/components/step-route/test/index.tsx
Outdated
Show resolved
Hide resolved
client/landing/stepper/declarative-flow/internals/components/step-route/index.tsx
Outdated
Show resolved
Hide resolved
client/landing/stepper/declarative-flow/internals/components/step-route/test/index.tsx
Outdated
Show resolved
Hide resolved
client/landing/stepper/declarative-flow/internals/components/step-route/test/index.tsx
Outdated
Show resolved
Hide resolved
@daledupreez I created a second PR, based on this on just to address the renderStep issue. #91345 |
Co-authored-by: daledupreez <dale@automattic.com>
…tep-route/test/index.tsx Co-authored-by: daledupreez <dale@automattic.com>
if ( ! siteSlug && ! siteId && ! isHostedSiteMigrationFlow( this.variantSlug ?? FLOW_NAME ) ) { | ||
window.location.assign( '/start' ); | ||
result = { | ||
|
||
return { | ||
state: AssertConditionState.FAILURE, | ||
message: 'site-setup did not provide the site slug or site id it is configured to.', | ||
}; | ||
} |
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 am wondering if we have two issues in this code block:
- This should be inside
useEffect()
- Should this code also be checking for whether we have a logged-in user?
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.
As a follow-up, I think this is another situation where we had an implicit dependency on the login redirect logic, which we've now removed.
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.
Fix pushed in 4614bf4.
It seems the /setup/site-migration flow is redirecting me to /start. Am I missing something? |
@alshakero |
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.
@gabrielcaires, I have re-tested, and I think we are OK to get this shipped. I can't approve as the original PR author, but let me know if you have any concerns about shipping this as-is.
Related to:
Fixes #91243
Proposed Changes
requiresLoggedInUser
flag that should be specified inflow.useSteps()
stepWithRequiredLogin()
andstepsWithRequiredLogin()
helpers to set this flag easilyStepRoute
component now checks whether the current step has a truthyrequiresLoggedInUser
value, and will not render any content if the user is also not logged in, as well as triggering a redirect to log the user in.useLoginUrlForFlow()
hook that builds on my explorations in Explore: new useFlowLoginUrl() hook for Stepper flows #90711calypso_signup_step_start
Tracks events has been moved fromFlowRenderer
toStepRoute
, and we won't trigger the Tracks event if theStepRoute
logic from above performs a login redirect for a step that requires a loginWhy are these changes being made?
calypso_signup_step_start
Tracks events even when the user doesn't see the step. This PR attempts to resolve this by "knowing" whether a specific step requires the user to be logged in, and performing a redirect when necessary, as well as skipping rendering and triggering a Tracks event when we know a redirect should occur.Testing Instructions
/setup/site-migration
, including:/setup/site-migration/
/setup/site-migration/site-migration-identify
/setup/site-migration/site-migration-import-or-migrate
/setup/site-migration/site-migration-upgrade-plan
/setup/site-migration/site-migration-instructions-i2
calypso_signup_step_start
Tracks event was recorded for thesite-migration
flow.calypso_signup_step_start
Tracks events for thesite-migration
flow.locale
URL parameter for some of the above URLs, and verify that you're redirected to the right login page with the locale in the path and the redirect URL for the login page includes the relevant non-English locale. You should still see nocalypso_signup_step_start
Tracks events for thesite-migration
flow.calypso_signup_step_start
event being fired correctly for thesite-migration
flowcalypso_signup_step_start
event being fired correctlyPre-merge Checklist