Remove design picker from site-setup flow

[p-jackson]

Related to #97383

Proposed Changes

Builds on the changes in #97383 which moves the design picker to the onboarding flow.

In the "goals first" experiment:

• Removes all steps from the site-setup flow other than those needed for processing
• Upon loading the site-setup flow, queues a processing job to apply the selected design to the selected site
  • The useSideEffects hook is mostly a copy-paste from the unified design picker's click handler:

    wp-calypso/client/landing/stepper/declarative-flow/internals/steps-repository/design-setup/unified-design-picker.tsx

    Line 644 in 955b414

    async function pickDesign( _selectedDesign: Design | undefined = selectedDesign ) {

CleanShot.2024-12-17.at.19.16.16.mp4

You still can't test premium themes/variations because this modal still blocks the user from moving forward. That can be removed in another PR.

Why are these changes being made?

For free sites with free themes it just needs to happen after site creation. It strikes me now that if a user chooses free everything we can do it in the onboarding flow before redirecting to /home
For paid themes, we need to be sure the user successfully completed checkout before we apply the design. That's why it has to be in a separate flow after the checkout.
This PR implements the separate flow, since that works for free and paid. But skipping the extra flow for free sites seems like a nice bit of polish.

Testing Instructions

• Test by running through the /setup/onboarding flow
  • Need to test using sites with a free plan and sites with paid plans. Both should have the theme applied to the site once the flow is complete
• Also make sure the /start flow hasn't changed! The /start flow eventually lands in the site-setup flow and it needs to still have the goals and design picker step working as expected

Pre-merge Checklist

• Has the general commit checklist been followed? (PCYsg-hS-p2)
• Have you written new tests for your changes?
• Have you tested the feature in Simple (P9HQHe-k8-p2), Atomic (P9HQHe-jW-p2), and self-hosted Jetpack sites (PCYsg-g6b-p2)?
• Have you checked for TypeScript, React or other console errors?
• Have you used memoizing on expensive computations? More info in Memoizing with create-selector and Using memoizing selectors and Our Approach to Data
• Have we added the "[Status] String Freeze" label as soon as any new strings were ready for translation (p4TIVU-5Jq-p2)?
  • For UI changes, have we tested the change in various languages (for example, ES, PT, FR, or DE)? The length of text and words vary significantly between languages.
• For changes affecting Jetpack: Have we added the "[Status] Needs Privacy Updates" label if this pull request changes what data or activity we track or use (p4TIVU-aUh-p2)?

[github-actions]

Calypso Live (direct link)

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

Jetpack Cloud live (direct link)

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

Automattic for Agencies live (direct link)

https://calypso.live?image=registry.a8c.com/calypso/app:build-127829&env=a8c-for-agencies

[matticbot]

This PR modifies the release build for the following Calypso Apps:

For info about this notification, see here: PCYsg-OT6-p2

• notifications

To test WordPress.com changes, run install-plugin.sh $pluginSlug update/dp-before-site-creation-2 on your sandbox.

[matticbot]

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

Sections (~548 bytes added 📈 [gzipped])

name             parsed_size           gzip_size
site-setup-wg        +2541 B  (+1.6%)     +548 B  (+1.7%)
site-setup-flow      +2541 B  (+1.6%)     +548 B  (+1.8%)

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.
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.

[arthur791004]

I'm curious why do we need to redirect to the site-setup flow after the onboarding in the "goals first" experiment?

[taipeicoder]

According to this comment #97383 (comment) it's so that we can reuse the flow for theme activation. Perhaps we can use another flow for this, like /with-theme?

[p-jackson]

@arthur791004 the issue is that we need somewhere to apply the design to the site.
For free sites with free themes it just needs to happen after site creation. It strikes me now that if a user chooses free everything we can do it in the onboarding flow before redirecting to /home
For paid themes, we need to be sure the user successfully completed checkout before we apply the design. That's why it has to be in a separate flow after the checkout.
This PR implements the separate flow, since that works for free and paid. But skipping the extra flow for free sites seems like a nice bit of polish.

@taipeicoder I'll take a look into the with-theme flow! I wasn't aware that there might already be a flow that could do this work for us. Part of me wonders whether it's better to use the main flow though, for the A/B test. There was some talk of disparities when trying to compare metrics between start and setup/onboarding. Maybe we want both variations of the experiment to use the exact same flow so that the metrics differ as little as possible?

[arthur791004]

Perhaps we can use another flow for this, like /with-theme?

There is another flow called update-design to allow users to change their design from the launchpad 😅

[arthur791004]

Oops...I misclicked the "Ready for review" 😓

[taipeicoder]

Is there a step that does the theme activation? If so, would bringing that step to /setup/onboarding work better?

[p-jackson]

@arthur791004 to hack things together and get it working we just passed an empty object here for globalStyles. It works, but I'm not sure why or whether this is a problem.

The design picker passes a proper globalStyles object here, but the data is loaded very indirectly, so I don't know the easy way to pass the global styles in here.

[arthur791004]

The empty object{} will clear the user's global styles on the selected theme because people may come from the existing sites.

[arthur791004]

hmmm...the preselected global styles can be loaded via query parameters but it needs to go through the Design Preview step to load the data...

I think we can address this in the follow-up PR.

[candy02058912]

I tried to see if things would work by changing this to use selectedGlobalStyles which is now loading from the store but it's not loading, would need more investigation for this.

[arthur791004]

Is there a step that does the theme activation? If so, would bringing that step to /setup/onboarding work better?

We don't have this step because the theme activation should happen when people finish the flow. If we activate the theme immediately, we have to do it again when people go back to the Design Picker....

[arthur791004]

Let's go 🚢

[candy02058912]

Getting the globalStyles and styleVariation still needs to be worked in a follow-up PR, but this is good to 🚢 to keep things going.

[candy02058912]

I tried to see if things would work by changing this to use selectedGlobalStyles which is now loading from the store but it's not loading, would need more investigation for this.