-
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
Domain-To-Plan Credit: Add plan notice for domain credits #98792
Conversation
Jetpack Cloud live (direct link)
Automattic for Agencies live (direct link)
|
Here is how your PR affects size of JS and CSS bundles shipped to the user's browser: Sections (~742 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 (~677 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. |
This PR modifies the release build for the following Calypso Apps: For info about this notification, see here: PCYsg-OT6-p2
To test WordPress.com changes, run |
b40c883
to
3679872
Compare
TestingRequirementsFlows:
Browsers
|
Since we're introducing a file named |
expect( result.current ).toEqual( 1000 ); | ||
} ); | ||
|
||
test( 'Returns credit when credit value is 0', () => { |
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.
Would you mind elaborating on the significance of this spec a bit more? It sounds like its important to differentiate between a $0 credit and no credit in this case 🤔
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.
Good question! The test verifies that the hook maintains a distinction between two different states: a site that is eligible but has no credit (hook returns 0
) versus a site that is not eligible (hook returns null
). While the distinction isn't utilised in the current UI, I think supporting the distinction in the hook makes it a bit more flexible, and the test helps avoid an accidental change that might conflate the two states.
I hope that makes sense?
I'll update the test description and comments to clarify.
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.
Yep makes sense thanks for clarifying :)
Alongside your inline comments, what do you think about adding a note clarifying that the distinction isn't currently utilized in the UI ( but may be in the future ? )
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 for taking care of this! Left a few comments but they're all non-blocking 🙂
Before you merge into production, would you mind hiding things behind a feature flag?
Good idea. I've applied the rename you suggested. |
aa356b3
to
39338b9
Compare
👍 Feature flag check has been added. |
6f51468
to
9141a3a
Compare
- Update `useDomainToPlanCreditsApplicable` to use `useMaxPlanUpgradeCredits` - Remove deprecated `useDomainToPlanCredits` hook - Modify test mocks to reflect new hook implementation - Add support for visible plans parameter in credits hook
- Remove test for null credit value - Update mock to use `useMaxPlanUpgradeCredits` instead of `useDomainToPlanCredits` - Adjust test expectations to match new hook implementation
- Add specific support URL for upgrade credits - Reorder domain-to-plan credit notice type in type definition - Update test description for domain-to-plan credit notice - Rename test description for domain-to-plan credits hook
To align with the naming used for the domain-to-plan credit notice
9141a3a
to
808e2bf
Compare
Rebased, proceeding with deploy 🚢 |
This Pull Request is now available for translation here: https://translate.wordpress.com/deliverables/17229341 Thank you @oswian for including a screenshot in the description! This is really helpful for our translators. |
Translation for this Pull Request has now been finished. |
Related to https://github.com/Automattic/martech/issues/3658
Proposed Changes
Requires: 170944-ghe-Automattic/wpcom
Displays a credit notice on the plans page for users who have unused credit after purchasing a domain and no plan.
Implementation notes:
client/my-sites/plans-features-main/components/plan-notice-credit-update.tsx
toplan-notice-credit-upgrade.tsx
('update' --> 'upgrade') as this appears to be an oversight, as the component itself is namedPlanNoticeCreditUpgrade
.plan-notice-credit-upgrade.tsx
, we are using a different hook internally to determine the applicability of the credits (useDomainToPlanCreditsApplicable
), and we are presenting a different user message. So while we could updateplan-notice-credit-upgrade.tsx
to handle both notices and avoid the duplication, I've instead opted to keep it simple and create a new component.Why are these changes being made?
To encourage folks who purchased a domain and only have a free plan to upgrade to a paid plan. Further context here.
Testing Instructions
/plans/:site?flags=domain-to-plan-credit
Pre-merge Checklist