-
Notifications
You must be signed in to change notification settings - Fork 2k
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
Plans: Add parameter to show only specific plans for the Jetpack app plan selection flow #77029
Conversation
…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
@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 |
Here is how your PR affects size of JS and CSS bundles shipped to the user's browser: Sections (~118 bytes added 📈 [gzipped])
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])
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. Generated by performance advisor bot at iscalypsofastyet.com. |
There was a problem hiding this 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.
…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
@guarani, you spotted it well. I don't think that's correct, even if it was unharmful for |
@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 🙇🏼 |
Thanks for the review, @southp! I appreciate it ❤️ |
TestingRequirementsNormal plan selection flow
Domain and plan package plan selection flow
Regression normal plan selection flow
Regression domain and plan package plan selection flow
Browsers
|
client/my-sites/plans/controller.jsx
Outdated
@@ -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 ) } |
There was a problem hiding this comment.
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:
- If we want to keep JSON.parse, I think this could be more readable as
JSON.parse( Boolean( context.query.domainAndPlanPackage ) )
- It appears you're using JSON.parse to handle string types that express boolean values E.G.
"true"
instead oftrue
. I would actually prefercontext.query.domainAndPlanPackage === "true"
because it more clearly represents our intentions of coercing some value. I'm unsure about any conventions either
There was a problem hiding this comment.
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 👍
There was a problem hiding this 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; |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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 👍
@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? |
From the Contributing docs, this needs a [Status] Ready to Merge label from a reviewer for it to be ready to merge. |
You should be good to go!
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 🚢 |
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! |
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 setplanTypes
props ofPlansFeaturesMain
component to limit plan selection to Personal and Premium Plans:Follow a similar pattern to #66022 which added
domainAndPlanPackage
parameterTesting Instructions
Normal plan selection flow
Domain and plan package plan selection flow
Regression normal plan selection flow
Regression domain and plan package plan selection flow
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