Plans Next: Relocate components into /shared

[oswian]

Resolves #87293

Proposed Changes

Relocates a number of components in the plans-grid-next package to make better use of /shared. No changes have been made to component functionality.

Components that previously lived in plans-grid-next/src/components/** have been moved into either:

• plans-grid-next/src/components/shared/** when the component is used by multiple components
• plans-grid-next/src/components/features-grid/** when the component is only used by <FeaturesGrid />
• plans-grid-next/src/components/comparison-grid/** when the component is only used by <ComparisonGrid/>

Several components have also been renamed:

• To remove the '2023' reference eg.
  • Plans2023Tooltip -> PlansTooltip
• To reflect that the component is used by more than just the features grid and now lives in /shared eg.
  • PlanFeatures2023GridActions -> PlanActions
  • PlanFeatures2023GridFeatures -> PlanFeatures

Testing Instructions

There should be no functional changes. Please smoke test the plans grids.

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[bot]]

Calypso Live (direct link)

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

Jetpack Cloud live (direct link)

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

[matticbot]

This PR does not affect the size of JS and CSS bundles shipped to the user's browser.

Generated by performance advisor bot at iscalypsofastyet.com.

[oswian]

@chriskmnds Sure, either approach works for me. The approach I adopted here seemed most efficient -- find a logical home for each component, and then address style changes in a followup. Both get the same result, I just find styling uses a different part of my 🧠 and can benefit from focus.

I'll go ahead and rework this into separate PR's per component (with style changes). I imagine there will be instances where it makes sense to bundle multiple/related components together, though.

[chriskmnds]

@chriskmnds Sure, either approach works for me. The approach I adopted here seemed most efficient -- find a logical home for each component, and then address style changes in a followup. Both get the same result, I just find styling uses a different part of my 🧠 and can benefit from focus.

I'll go ahead and rework this into separate PR's per component (with style changes). I imagine there will be instances where it makes sense to bundle multiple/related components together, though.

Thanks. We took a similar approach previously, where empty folders were created at places (/npm-ready) and gradually hooks & components migrated there in their complete state. So at any point we could trust those were "ready" and needn't be worked on further. and we could nudge people "hey, don't do this or that in this folder". It was different though, so if you find the alternative (move everything now and update next), then we can go with that.

^ feel free to pick the way forward and I will follow up with it. I mainly wanted to highlight that we need to gradually be "fixing" internally where it needs fixing (classes, names, styles, etc.). it wasn't clear from the description :-)

[oswian]

@chriskmnds Thanks for taking a look over this.

I mainly wanted to highlight that we need to gradually be "fixing" internally where it needs fixing (classes, names, styles, etc.). it wasn't clear from the description :-)

Good point, my bad -- the description didn't articulate the approach very clearly.

^ feel free to pick the way forward and I will follow up with it.

I'm going to try extracting these changes into separate PR's that incorporate style changes, along with your suggestions above re: plan- prefix removal, internal 'fixes' etc.