Checkout: Convert CompositeCheckout component to TypeScript

[sirbrillig]

Changes proposed in this Pull Request

This converts the main component in new checkout, CompositeCheckout, to TypeScript. In the process, it fixes several small bugs and type errors.

Testing instructions

This touches nearly all aspects of checkout, but it's impossible to test them all, and like many other recent refactors, if anything serious is broken by this, it should be obvious quickly.

Notable changes:

• arguments has been removed from the THANK_YOU_URL_GENERATED analytics event. They have actually been missing since Checkout: Convert getThankYouUrl to TypeScript #46423. It would be nice to add them back in, but getting them out of the hook is actually non-trivial and I'd rather that be in its own PR. For the moment, this just removes the unused property. This should have no effect, but it might be worth examining the event when it runs to be sure it's working.
• This movesdoesValueExist to a top-level helper in the composite checkout directory which can be used as [].filter(doesValueExist) in place of [].filter(Boolean) to please TypeScript. This should have no user-facing effect as long as it filters out falsy values correctly. If it doesn't, we'd probably see lots of errors about adding products when no product add errors exist.
• This makes useRedirectIfCartEmpty more explicit about when it will and won't redirect; there's now a single argument, doNotRedirect, which is used for that decision, putting the logic fully in the consumer. Worth testing that we are still redirected when we'd expect to be, and are not redirected if the cart is empty and an invalid product slug is in the URL.

[matticbot]

Test live: https://calypso.live/?branch=update/calypso-composite-checkout-to-typescript

[matticbot]

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

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

name        parsed_size           gzip_size
entry-main       +164 B  (+0.0%)      +46 B  (+0.0%)

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

Sections (~628 bytes removed 📉 [gzipped])

name             parsed_size           gzip_size
checkout             -3183 B  (-0.2%)     -623 B  (-0.1%)
site-purchases         -34 B  (-0.0%)       -5 B  (-0.0%)
purchases              -34 B  (-0.0%)       +4 B  (+0.0%)
plans                  -34 B  (-0.0%)       +0 B
migrate                -34 B  (-0.0%)       -6 B  (-0.0%)
jetpack-connect        -34 B  (-0.0%)       +1 B  (+0.0%)
domains                -34 B  (-0.0%)       +1 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.

Async-loaded Components (~878 bytes removed 📉 [gzipped])

name                                                 parsed_size           gzip_size
async-load-calypso-blocks-editor-checkout-modal          -4042 B  (-0.4%)     -902 B  (-0.3%)
async-load-calypso-blocks-inline-help                     +164 B  (+0.1%)      +41 B  (+0.1%)
async-load-signup-steps-plans-atomic-store                 -34 B  (-0.0%)       -6 B  (-0.0%)
async-load-signup-steps-plans                              -34 B  (-0.0%)       -5 B  (-0.0%)
async-load-signup-steps-domains                            -34 B  (-0.0%)       -4 B  (-0.0%)
async-load-design-blocks                                   -34 B  (-0.0%)       +0 B
async-load-calypso-components-web-preview-component        -34 B  (-0.0%)       -2 B  (-0.0%)

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

[nbloomf]

I see some odd behavior when renewing a plan; it also happens on master so is not related to this PR. Reported at https://github.com/Automattic/payments-shilling/issues/37

[sirbrillig]

Yeah, good find. We'll need to modify the getThankYouPageUrl function to be aware of the difference between site-level and account-level. Or maybe just always default to site-level? Anyway, we can figure that out later.

[nbloomf]

I tried a bunch of flows and didn't see any behavioral bugs. This is not exhaustive, but as you say, exhaustive testing would take a long time and if this does break something it should be clear quickly.

• Renewing a plan
• Upgrading a plan from a persistent cart
• Adding a plan upgrade to the cart from the URL
• Emptying the cart from within checkout

I checked for a "THANK_YOU_URL_GENERATED" event, and it looks normal:

I did see a couple of relevant looking console errors while navigating around checkout, but they did not cause any visible problems or prevent checkout from completing:

(Don't think these are related to each other)

[nbloomf]

Looks good and works as described!

[sirbrillig]

Rebased after #46671