-
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
Stepper: calypso_signup_complete as in Start #94706
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 (~99 bytes added 📈 [gzipped])
Common code that is always downloaded and parsed every time the app is loaded, no matter which route is used. Sections (~1241 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 (~7 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. |
@@ -18,16 +23,16 @@ export const useRecordSignupComplete = ( flow: string | null ) => { | |||
selectedDomain: ( select( ONBOARD_STORE ) as OnboardSelect ).getSelectedDomain(), | |||
}; | |||
}, [] ); | |||
const isNewishUser = isUserRegistrationDaysWithinRange( state, null, 0, 7 ); | |||
const dependencies = getSignupDependencyStore( state ); |
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 for myself:
I need to figure why getSignupDependencyStore always returns an {}
a0974f7
to
fabcdf2
Compare
This PR modifies the release build for the following Calypso Apps: For info about this notification, see here: PCYsg-OT6-p2
To test WordPress.com changes, run |
@@ -3,68 +3,81 @@ import { useSelect } from '@wordpress/data'; | |||
import { useCallback } from 'react'; | |||
import { USER_STORE, ONBOARD_STORE } from 'calypso/landing/stepper/stores'; | |||
import { SIGNUP_DOMAIN_ORIGIN, recordSignupComplete } from 'calypso/lib/analytics/signup'; | |||
import { useSelector } from 'calypso/state'; | |||
import isUserRegistrationDaysWithinRange from 'calypso/state/selectors/is-user-registration-days-within-range'; | |||
import { useSite } from './use-site'; | |||
import type { UserSelect, OnboardSelect } from '@automattic/data-stores'; | |||
|
|||
export const useRecordSignupComplete = ( flow: string | null ) => { | |||
const site = useSite(); |
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.
@escapemanuele is this where the issue stems? It looks like it grabs site ID/slug from URL params, which would obviously be undefined
unless carried along?
Isn't there a store/state slice that gets populated with site ID when one is created? We should probably look at create-site step and do that if not?
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.
What I ended up doing is passing the data from the processing step directly when calling the useRecordSignupComplete function here. At that point we have all the data needed. Do you think that should be changed?
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.
Cool. Sounds good (you obviously know more about these concepts)
Do you think that should be changed?
I'm not sure. It might not be a bad idea to populate the onboard store with it once a site is created (or pending). It would make it available in anything that follows and needs it.
I will comment up above on something related if you can also take a look pls
@@ -21,6 +24,9 @@ export function useCreateAccountMutation() { | |||
} ); | |||
}, | |||
onSuccess: ( data ) => { | |||
if ( 'isNewAccountCreated' in data && data.isNewAccountCreated ) { | |||
setIsNewUser( true ); |
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.
One thing that, I think, would be nice to make sure it is clear is that the user will be "newUser" just once. For instance, if you create the user, then land on the domain's step and refresh the page, the user is not new anymore.
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.
Well, we could persist that, but I'm always worried about persistence bugs 🤔
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.
Well, we could persist that, but I'm always worried about persistence bugs 🤔
I think we could have a better definition of what is a "newUser"
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 replicated what is done during user creation here https://github.com/Automattic/wp-calypso/blob/trunk/client/lib/signup/api/account.tsx#L120 😄
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.
Some differences I noticed /setup
vs /start
/setup
includes a few extra props: starting_point
, theme
, intent
I went through /setup
with an existing user and the elapsed_time_since_start
is logged as null.
Thank you @agrullon95!
|
Just to note here that with #94743 if a flow uses something like:
(or through the current I think there are two solutions (outside of ignoring
I think it's not a blocker for the experiment as we don't use |
Good catch @chriskmnds, I believe we can open an issue to keep that into consideration! |
@@ -104,7 +104,7 @@ const ProcessingStep: React.FC< ProcessingStepProps > = function ( props ) { | |||
if ( availableFlows[ flow ] ) { | |||
availableFlows[ flow ]().then( ( flowExport ) => { | |||
if ( flowExport.default.isSignupFlow ) { | |||
recordSignupComplete(); | |||
recordSignupComplete( { ...destinationState } ); |
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.
Just roughly thinking. I get the impression that a specific step should not control and record the signup-complete event. I would expect this to be triggered via a flow unmount effect (where we equally observe for some "success" flag) or to actually mark a step as the "signup completion" step (so any step can be used for closing). WDYT?
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 thought the same as well! But having found the recordSignupComplete
I doubted that maybe there was some big decision behind this while I was not involved in Stepper work.
Moreover, useSignUpStartTracking
is in FlowRenderer. Logically, it makes sense to have the signup complete at a framework, and not step, level too. But I wonder if that's overcomplicated. It would be better to open an issue.
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, definitely something for a follow-up issue. It does make sense to have this near/in useSignUpStartTracking
. It will probably lead to more holistic refactor, but we want these things to be perfect! :D
Cool. Opened #94767 |
* Use same tracking values as in start * Pass destinationState to signup completion tracking * Add newUser call * Register in the store when it is a new account * Better check --------- Co-authored-by: escapemanuele <escapemanuele@gmail.com>
Fixes #94688
Proposed Changes
isNewUser
andisNew7DUserSite
values, these values are used to properly log thecalypso_signup_complete
tracking event.Why are these changes being made?
/start
logic.Testing Instructions
calypso_signup_complete
gets triggered correctly, with the blog_id