[Goals Capture] Display Continue button in goals capture screen

[mashikag]

Proposed Changes

• Implement Continue button to goals capture screen

Before (Desktop and Mobile)

No Continue button at Goals capture step screen.

After (Desktop and Mobile)

Continue button is present.

Testing Instructions

1. Checkout this branch locally.
2. In config/development.json set signup/goals-step property to true
3. Build and run wp-calypso locally.
4. Navigate to http://calypso.localhost:3000/setup/goals?siteSlug=<YOUR SITE'S ADDRESS HERE>, e.g.: http://calypso.localhost:3000/setup/goals?siteSlug=blajh198278453.wordpress.com
5. Test for Continue button being displayed.

Related to #63921

[matticbot]

Calypso Live (direct link)

https://calypso.live?image=registry.a8c.com/calypso/app:build-35694

Jetpack Cloud live (direct link)

https://calypso.live?image=registry.a8c.com/calypso/app:build-35694&env=jetpack

[matticbot]

Here is how your PR affects size of JS and CSS bundles shipped to the user's browser:

App Entrypoints (~63 bytes added 📈 [gzipped])

name                 parsed_size           gzip_size
entry-stepper             +292 B  (+0.0%)      +63 B  (+0.0%)
entry-gutenboarding        +22 B  (+0.0%)      +12 B  (+0.0%)

Common code that is always downloaded and parsed every time the app is loaded, no matter which route is used.

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.
Gzip Size: Compressed size of the JS and CSS files. This much data needs to be downloaded over network.

Generated by performance advisor bot at iscalypsofastyet.com.

[phcp]

Looks good! From the code perspective I like that you changed the SelectCard component to use generics, that way we earn more flexibility and avoid casting the value.

The navigation flow is working as expected and the Continue button is disabled until the user select a goal.

[yansern]

The 3 issues that need to be addressed are:

• Flow routing needs changes. See further comment here.
• The "Continue" button behavior when no goals are selected.
• Untranslated strings.

For future work, I would recommend, where possible, breaking compound work down into separate PRs to make things easier to review.

[yansern]

Actually, user should be allowed to click Continue button when no goals are selected. When no goals are selected, it should route to the build flow, meaning the intent is build.

Be aware of the subtle difference:

• Continue button's intent is build when no goals are selected.
• Skip button's intent is wpadmin.

Have a feeling something needs to change in the goalsToIntent mapping function. Let me know what you find out! :)

Context: p1653902033117909-slack-C02TCEHP3HA

[mashikag]

Hmmm... Ok. I will make the button always enabled then. However the fix to have the build intent selected by default, if no goals are selected, will need to be addressed in another PR. It will add a little bit more complexity because we will need to ensure that this default value is only set (locally and remotely) when goals capture screen is used.

[yansern]

Nit: Not sure if this should be WPAdmin, wpAdmin or WpAdmin. All 3 use cases seem to exist across different codebases.

[yansern]

Relooking this PR with fresher eyes and more focus on the routing part, there are some routing issues that need to align more to the flow on whimsical.

[yansern]

Given that this context is under goBack(), something feels off here.

1. When the current step is intent, we know that this is a version of the onboarding flow that doesn't have Goals Capture, and therefore replacing intent with intentCaptureStep is likely incorrect, as intentCaptureStep could be either intent or goals.
2. Goals Capture will be the first step, Verticals is the second step, so a case for handling go-back flow when vertical is the second step is likely needed.

case 'intent':
	return navigate( isEnabled( 'signup/site-vertical-step' ) ? 'vertical' : 'intent' );
case 'vertical':
    // the latter part of is something I'm unsure of
    return navigate( isEnabled( 'signup/goals-step') ? 'goals' :  'vertical' ); 

[yansern]

If V13N is enabled, this should first route to the Verticals step. And after the Verticals step is completed, it should continue with the logic above. See more about post-verticals routing comment below.

If V13N is not enabled, where import flow should go is still a question that needs addressing.

[yansern]

Under the scenario where both GC + V13N are enabled, it should:

1. Check if the goal import is selected, and route to Import flow import.
2. Check if the intent is write or sell, then route to Write/Sell flow options.
3. Else if the intent is build, then route to Build flow designSetup.

Can't wrap my headspace around this at the moment, but double-check for possible scenarios like:

• No V13N
• V13N only
• GC with V13N
• GC only (without V13N)

[mashikag]

What about the difm goal/intent was selected? Do we still go through vertical step? And then, only after, exit out to /start/website-design-services/?siteSlug=${ siteSlug }? Or we skip the vertical step then and exit out directly from goals capture screen?

[yansern]

After reviewing the flow routing issues, I think those mentioned issues need to be addressed before the PR can be merged.

Or split the site-setup-flow.ts changes to another PR, and address other issues in the comments above in other smaller PRs.

[yansern]

Thanks a lot! Let's roll it in.