Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Plans: Add parameter to show only specific plans for the Jetpack app plan selection flow #77029

Merged
merged 10 commits into from
May 31, 2023

Conversation

staskus
Copy link
Contributor

@staskus staskus commented May 17, 2023

Related to #76968

Details

pcdRpT-2Bo-p2
Scope: pc8eDl-Vv-p2
Discussion: p1684158877461119-slack-CFFF01Q4V

Create a WP.com Plans selection for the Jetpack app limiting it to only showing WP.com Personal and Premium plans.

Proposed Changes

Check jetpackAppPlans parameter to set planTypes props of PlansFeaturesMain component to limit plan selection to Personal and Premium Plans:

  • /plans/{siteURL}?jetpackAppPlans=true
  • /plans/yearly/{siteURL}?domainAndPlanPackage=true&jetpackAppPlans=true

Follow a similar pattern to #66022 which added domainAndPlanPackage parameter

Testing Instructions

Normal plan selection flow

  1. Select simple/atomic site
  2. Visit /plans/{siteURL}?jetpackAppPlans=true page
  3. Confirm that only personal and premium plans are visible
  4. Switch between annual and monthly plans
  5. Confirm that only personal and premium plans are visible
  6. Confirm that after selecting the plan, the checkout view is opened

Domain and plan package plan selection flow

  1. Select simple/atomic site
  2. Visit /plans/yearly/{siteURL}?domainAndPlanPackage=true&jetpackAppPlans=true page
  3. Confirm that only personal and premium plans are visible
  4. Confirm that header with steps and back button is not visible
  5. Confirm that after selecting the plan, the checkout view is opened

Regression normal plan selection flow

  1. Select simple/atomic site
  2. Visit /plans page
  3. Confirm that all the available plans are offered

Regression domain and plan package plan selection flow

  1. Select simple/atomic site
  2. Visit /plans/yearly/{siteURL}?domainAndPlanPackage=true page
  3. Confirm that all the available plans are offered
  4. Confirm that header with steps and back button appears on top

Videos

Before. Plans for domain and plan package

Plans.Purchasing.Before.mov

After. Plans for domain and plan package and jetpackAppPlans=true

plan.and.domain.purchasing.flow.new.mov

After. Plans with jetpackAppPlans=true

plan.only.purchase.new.mov

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

staskus added 3 commits May 17, 2023 17:42
…s set

Support configuring wp.com/plans/yearly/{siteURL} flow with jetpackAppPlans parameter, that limits the number of plans shown to support Jetpack app-specific flows
…arameter is set

Support the Jetpack app plan purchasing flows by hiding a navigation header that displays the position inside domain and plan upsell flow and allows to come back
@staskus staskus added [Feature] Plans & Upgrades All of the plans on WordPress.com and flow for upgrading plans. [Type] Task Mobile Application WordPress.com App for mobile labels May 17, 2023
@staskus staskus requested review from southp and guarani May 17, 2023 14:44
@matticbot matticbot added the [Status] Needs Review The PR is ready for review. This also triggers e2e canary tests and wp-desktop tests automatically. label May 17, 2023
@github-actions
Copy link

github-actions bot commented May 17, 2023

@staskus
Copy link
Contributor Author

staskus commented May 17, 2023

@southp, we would be thankful if you could take a look at this PR when you're available. Since we're not contributing to Calypso often, let us know if anything is missing. Thank you!

CC: @ravishanker, @irfano, @guarani

@matticbot
Copy link
Contributor

matticbot commented May 17, 2023

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

Sections (~118 bytes added 📈 [gzipped])

name                  parsed_size           gzip_size
plans                      +286 B  (+0.0%)      +81 B  (+0.0%)
update-design-flow          +87 B  (+0.0%)      +21 B  (+0.0%)
plugins                     +87 B  (+0.0%)      +16 B  (+0.0%)
link-in-bio-tld-flow        +87 B  (+0.0%)      +21 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 (~21 bytes added 📈 [gzipped])

name                                             parsed_size           gzip_size
async-load-signup-steps-plans-theme-preselected        +87 B  (+0.0%)      +21 B  (+0.0%)
async-load-signup-steps-plans-pm                       +87 B  (+0.0%)      +21 B  (+0.0%)
async-load-signup-steps-plans                          +87 B  (+0.0%)      +21 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.

Copy link
Contributor

@guarani guarani left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👋 This looks good @staskus!
There might be a convention that values of true and false for "boolean" query params are equivalent, but I haven't found one. However, jetpackAppPlans follows the same convention set by domainAndPlanPackage, so this seems OK.

I tested locally using the quick start testing steps and it worked as per the test plan. I can't see any potential regressions so I think this is good from my side.

Let me know if I should provide an approval or leave that for another reviewer.

staskus added 2 commits May 18, 2023 14:20
…both true and false values

Parse using JSON.parse so parameter=true would be correctly parsed as a true Boolean and parameter=false would be parsed as a false Boolean
@staskus
Copy link
Contributor Author

staskus commented May 18, 2023

There might be a convention that values of true and false for "boolean" query params are equivalent, but I haven't found one. However, jetpackAppPlans follows the same convention set by domainAndPlanPackage, so this seems OK.

@guarani, you spotted it well. I don't think that's correct, even if it was unharmful for domainAndPlanPackage. I made a fix to parse values to Booleans.

@southp
Copy link
Contributor

southp commented May 26, 2023

@staskus Sorry for the late response. I've tested it and it works well in general. However, I'm running out of time to look into the code deeper and to go through potential regression parts. I'll ping the team for a more timely review 🙇🏼

@guarani
Copy link
Contributor

guarani commented May 26, 2023

Thanks for the review, @southp! I appreciate it ❤️

@jeyip
Copy link
Contributor

jeyip commented May 26, 2023

Testing

Requirements

Normal plan selection flow

  • Visit /plans/{siteURL}?jetpackAppPlans=true page. Confirm that only personal and premium plans are visible.
  • Switch between annual and monthly plans. Confirm that only personal and premium plans are visible.
  • Confirm that the plans comparison grid only shows personal and premium plans.
  • Confirm that after selecting the plan, the checkout view is opened

Domain and plan package plan selection flow

  • Visit /plans/yearly/{siteURL}?domainAndPlanPackage=true&jetpackAppPlans=true page. Confirm that only personal and premium plans are visible.
  • Confirm that header with steps and back button is not visible
  • Confirm that after selecting the plan, the checkout view is opened

Regression normal plan selection flow

  • Visit /plans page. Confirm that all the available plans are offered.
  • Confirm that after selecting the plan, the checkout view is opened

Regression domain and plan package plan selection flow

  • Visit /plans/yearly/{siteURL}?domainAndPlanPackage=true page. Confirm that all the available plans are offered.
  • Confirm that header with steps and back button appears on top
  • Confirm that after selecting the plan, the checkout view is opened

Browsers

  • Chrome

@@ -38,7 +38,8 @@ export function plans( context, next ) {
? context.query.addDomainFlow === 'true'
: undefined
}
domainAndPlanPackage={ context.query.domainAndPlanPackage }
domainAndPlanPackage={ JSON.parse( context.query.domainAndPlanPackage ?? false ) }
Copy link
Contributor

@jeyip jeyip May 26, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Non-blocking / nitpick:

Two notes here:

  1. If we want to keep JSON.parse, I think this could be more readable as JSON.parse( Boolean( context.query.domainAndPlanPackage ) )
  2. It appears you're using JSON.parse to handle string types that express boolean values E.G. "true" instead of true. I would actually prefer context.query.domainAndPlanPackage === "true" because it more clearly represents our intentions of coercing some value. I'm unsure about any conventions either

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks! That's is a good idea to explicitly check for the "true" case rather than doing parsing and conversion that obscures the readability of the code 👍

Copy link
Contributor

@jeyip jeyip left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I haven't working in plans for too long, but from what I can tell, this tests well, and I only have smaller non-blocking concerns. 🚢

@@ -259,6 +261,7 @@ class Plans extends Component {
}

const hideFreePlan = ! is2023PricingGridVisible || this.props.isDomainAndPlanPackageFlow;
const planTypes = this.props.jetpackAppPlans ? [ TYPE_PERSONAL, TYPE_PREMIUM ] : null;
Copy link
Contributor

@jeyip jeyip May 26, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Non-blocking / nitpick:

Spitballing here, but wondering if a small inline comment might be useful?

// The jetpack mobile app only wants to display two plans -- personal and premium

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, I think the more explicit we are in such cases the better so the comment would only increase the clarity by expressing intentions 👍

@staskus
Copy link
Contributor Author

staskus commented May 30, 2023

@jeyip thank you for the review, I really appreciate that!

Is it enough to merge or are any additional actions required for the changes to be deployed?

@guarani
Copy link
Contributor

guarani commented May 31, 2023

From the Contributing docs, this needs a [Status] Ready to Merge label from a reviewer for it to be ready to merge.

@jeyip jeyip added [Status] Ready to Merge and removed [Status] Needs Review The PR is ready for review. This also triggers e2e canary tests and wp-desktop tests automatically. labels May 31, 2023
@jeyip
Copy link
Contributor

jeyip commented May 31, 2023

Is it enough to merge or are any additional actions required for the changes to be deployed?

You should be good to go!

From the Contributing docs, this needs a [Status] Ready to Merge label from a reviewer for it to be ready to merge.

@guarani

I’m not sure if there’s something particular to the part of the codebase updated in this PR, but I haven’t used the “Ready to Merge” label in any Calypso dev workflows before. Apologies if it was blocking progress on the PR, but, for me, everything seems fine to merge 🚢

@guarani
Copy link
Contributor

guarani commented May 31, 2023

I’m not sure if there’s something particular to the part of the codebase updated in this PR

I might have mis-read the docs or come across outdated ones, because I'm new to the Calypso codebase here.

No worries and thanks for the help on this PR, @jeyip! ❤️

I'm going to go ahead and merge now. Nice work on this, @staskus!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Feature] Plans & Upgrades All of the plans on WordPress.com and flow for upgrading plans. Mobile Application WordPress.com App for mobile [Type] Task
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants