Add queryParam to invalid cache when navigating away from site setup flow

[agrullon95]

Testing/Review:

Test: short
Review: short

Proposed Changes

• After a user walks through the general onboarding and selects a launchpad enabled goal (Write or Build), the user may be navigated to the home screen instead of the launchpad screen. These changes add the postOnboarding=true query parameter to site setup exit flow redirection URL, invalids the site data and fetches it again.

Testing Instructions

• Check out this branch
• yarn start
• Start general onboarding at calypso.localhost:3000/start
• At the goals step, select the write site intent
• Click on continue
• Click on the skip to dashboard button
• The user should see the postOnboarding=true query param in the /home url before being redirected to Launchpad
• If the redirect is too fast to see, then comment out the following code

  wp-calypso/client/my-sites/customer-home/controller.jsx

  Lines 55 to 62 in 70ac415

  	if ( shouldRedirectToLaunchpad ) {
  	// The new stepper launchpad onboarding flow isn't registered within the "page"
  	// client-side router, so page.redirect won't work. We need to use the
  	// traditional window.location Web API.
  	const verifiedParam = new URLSearchParams( window.location.search ).has( 'verified' );
  	redirectToLaunchpad( slug, refetchedOptions?.site_intent, verifiedParam );
  	return;
  	}

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 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-ajp-p2)?

Related to #72872

[github-actions]

Calypso Live (direct link)

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

Jetpack Cloud live (direct link)

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

[jeyip]

Paired with @agrullon95 on this so +1 from me

[matticbot]

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

Sections (~67 bytes added 📈 [gzipped])

name             parsed_size           gzip_size
site-setup-flow        +88 B  (+0.0%)      +43 B  (+0.0%)
home                   +60 B  (+0.0%)      +24 B  (+0.0%)

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.

[Addison-Stavlo]

should we get and read the query args specifically here?

[Addison-Stavlo]

side note, if we are only adding the arg from launchpad flows, then we could maybe just use that itself as the indication to redirect back to the launchpad here as opposed to refetching? Although, maybe the refetching is good to do in the first place anyways to make sure calypso store is truly up to date.

[jeyip]

should we get and read the query args specifically here?

Could you elaborate on this?

if we are only adding the arg from launchpad flows, then we could maybe just use that itself as the indication to redirect back to the launchpad here as opposed to refetching?

If we don't force a refetch, even if we redirect to Launchpad, the site option data in redux still might be stale if they happen to navigate to my home. I believe, however, if the user visits /view or the post or site editor ( the only pages the user can navigate to from the Launchpad ), the cache should be invalidated and things should behave as expected, but I'm not sure

[Addison-Stavlo]

Could you elaborate on this?

Sure, its probably not a big deal at all but right now we are just parsing the entire string of the URL to see if "postOnboarding=true" is part of the string. As opposed to getting the specific params out of the URL and checking their values. This might generally be something like $_GET in php or maybe searchParams in JS (maybe theres another method im not remembering). That said, Its probably not a big deal. We aren't going to see postOnboarding=true elsewhere in the URL string so it should work the same way.

If we don't force a refetch, even if we redirect to Launchpad, the site option data in redux still might be stale if they happen to navigate to my home. I believe if we visit /view or the editors the cache should be invalidated, but I'm not sure

That makes sense 👍

[sharpirate]

Testing

1. Start general onboarding at calypso.localhost:3000/start
2. At the goals step, select the write site intent
3. Click on continue
4. Click on the skip to dashboard button
   ✅ The user should see the postOnboarding=true query param in the /home url before being redirected to Launchpad