Plans (Storage): More base cleanup of existing hooks/props

[chriskmnds]

Related to #90905
Based on #91050

Proposed Changes

Additional refactors across storage add-ons/options logic:

• clarity on types (add-ons VS features)
• reduce prop drilling (most cases can just query the AddOns data store apparently)
• eliminate redundant properties on GridPlan (e.g. storageAddOnsForPlan)
• eliminate repeated logic across the Comparison & Features grid (there are core conditional chains that are repeated across)
• move storage-related code under /src/components/storage and expose a single StorageFeature component. This is now generic and wrapped by the element that the respective grid needs to render.
• rewrite useGetAvailableStorageOptions to useAvailableStorageOptions (no longer called in a loops)
• etc. (ongoing)

Why are these changes being made?

Fairly critical parts of the code that need to be guarded behind concrete types, abstractions, a more DRY layer.

TODO

• In a follow-up: Migrate and centralize all of the styles into /src/components/storage/styles.scss

Testing Instructions

• Everything add-ons. TBD

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

[github-actions]

Calypso Live (direct link)

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

Jetpack Cloud live (direct link)

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

Automattic for Agencies live (direct link)

https://calypso.live?image=registry.a8c.com/calypso/app:build-110878&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
• wpcom-block-editor

To test WordPress.com changes, run install-plugin.sh $pluginSlug update/plans-next-storage-cleanup-calls-and-props on your sandbox.

[matticbot]

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

Sections (~89 bytes removed 📉 [gzipped])

name                  parsed_size           gzip_size
update-design-flow         -481 B  (-0.0%)      -89 B  (-0.0%)
plugins                    -481 B  (-0.0%)      -89 B  (-0.0%)
plans                      -481 B  (-0.0%)      -89 B  (-0.0%)
link-in-bio-tld-flow       -481 B  (-0.0%)      -89 B  (-0.0%)
jetpack-app                -481 B  (-0.1%)      -89 B  (-0.1%)

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 (~89 bytes removed 📉 [gzipped])

name                                             parsed_size           gzip_size
async-load-signup-steps-plans-theme-preselected       -481 B  (-0.1%)      -89 B  (-0.1%)
async-load-signup-steps-plans                         -481 B  (-0.1%)      -89 B  (-0.1%)

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.

[chriskmnds]

I think addOnSlug should now be renamed now that the real type is reflected. It can either be the add-on slug or a feature slug. We didn't make this distinction previously and worked the code around it from the looks of it. This is now the "selected storage option slug"

cc @jeyip if you can confirm :-)

[jeyip]

I'll take a look later today 🙂

[jeyip]

Yes you're correct. In my original implementation, I had set up the selected storage option slice of state to only be meaningful if a 50GB or 100GB storage add-on was selected. Otherwise, I had used some false-y value to represent that no add-on was chosen and that the plan's default storage option was currently selected.

As time went on I introduced storage feature slugs as a possible selected storage option slug value. I honestly can't remember why I did so, because looking at the surrounding code, it seems that if we had continued to equate a false-y storage option to default storage instead of an add-on, things would've been fine as well 🤔

Either way, the type you've added does accurately reflect the "addOnSlug" property, and I agree that it should be renamed given that its possible slugs aren't solely add-ons.

[chriskmnds]

Thanks @jeyip . It makes sense. The implementation evolved properly, meaning we do populate this variable with either the add-on/upgrade feature or the standard plan feature. The current changes aren't touching the implementation side. Just adjusting the tuypes a little.

It might just be a case of renaming to slug. I'll revisit this in a follow-up.

[oswian]

Hi @chriskmnds. These changes are quite extensive and I assume will need thorough review / testing. I won't get to it today and may be AFK from next week on jury duty. 'May' be as jury duty is unpredictable and I might not be selected 🤷.

Flagging this to avoid blocking. In my previous role we could re-select a random reviewer by commenting on a PR. I haven't come across that approach in Calypso.

[oswian]

Testing Instructions: Everything add-ons. TBD

@chriskmnds Are you able to clarify the status of this PR, in terms of the 'TBD'? Are you planning further updates?

The discussion above between you and @jeyip implies some shared experience with the 'add-ons' functionality. I don't have this context, so without clear testing instructions I'm not sure how to proceed with the review.

[chriskmnds]

Testing Instructions: Everything add-ons. TBD

@chriskmnds Are you able to clarify the status of this PR, in terms of the 'TBD'? Are you planning further updates?

The discussion above between you and @jeyip implies some shared experience with the 'add-ons' functionality. I don't have this context, so without clear testing instructions I'm not sure how to proceed with the review.

Apologies @oswian . You are correct, there is a bit of context around these changes. I will run a few more basic tests and proceed to deploy. We can revert or revisit if any regressions prop up.