ref: delete mail #934
ref: delete mail #934
Conversation
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
WalkthroughThe pull request introduces significant modifications across multiple components by removing email-related functionality. This includes the elimination of email state management, validation, and associated UI elements from components such as Changes
Assessment against linked issues
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
fricoben
added
🚧 In progress do not merge
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🧹 Outside diff range and nitpick comments (3)
context/FormProvider.tsx (1)
Email functionality still actively used and needs proper removal plan
The verification shows that email-related code is not just legacy code but is actively integrated:
- Newsletter functionality is still active with dedicated pages
- Email validation is imported and used in
pages/newsletter.tsx- Components with email references are used in active pages:
subscription.tsxfreerenewal.tsxThis suggests that removing email functionality requires a broader refactoring effort beyond the current changes. The removal should be handled in a separate, dedicated PR that:
- Removes the newsletter feature completely
- Updates the subscription and renewal flows to remove email dependencies
- Removes email-related utilities and tests
- Updates connector naming in
connectorWrapper.ts🔗 Analysis chain
Line range hint
1-124: Verify complete removal of email collection across the codebaseWhile the changes in these files correctly remove email functionality, we should verify complete removal across the entire codebase, including:
- API endpoints
- Database schemas
- Configuration files
- Documentation
Email-related code still present in multiple locations
Several files still contain email-related functionality that should be removed:
utils/stringService.ts: ContainsisValidEmailvalidation functionutils/connectorWrapper.ts: References "Email" connector namepages/newsletter.tsxandpages/newsletter/confirm.tsx: Complete newsletter pages with email functionality- Multiple components still have email-related code:
components/domains/autorenewal.tsxcomponents/domains/steps/checkoutCard.tsxcomponents/discount/registerDiscount.tsxcomponents/discount/freeRenewalCheckout.tsxLet me verify if these files are actually being used or just legacy code:
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Comprehensive check for remaining email-related code echo "Checking for email-related code..." rg -i "email" . echo "Checking for email-related API endpoints..." rg -i "api.*email|email.*api" . echo "Checking for email-related environment variables..." rg -i "email" .env* || true echo "Checking for email-related documentation..." rg -i "email" docs/ README.md || trueLength of output: 3607
Script:
#!/bin/bash # Check for imports of email-related functionality echo "Checking for imports of isValidEmail..." rg -l "import.*isValidEmail" . echo "Checking for newsletter page routes..." rg -l "newsletter" pages/_app.tsx pages/index.tsx echo "Checking component usage..." rg -l "autorenewal|checkoutCard|registerDiscount|freeRenewalCheckout" pages/Length of output: 470
components/domains/steps/userInfoForm.tsx (1)
116-116: Remove unnecessary empty line.This empty line appears to be left after removing the email-related form field.
- -components/discount/registerDiscount.tsx (1)
Line range hint
49-49: Remove unused mailGroups propThe
mailGroupsprop in the component props is no longer needed since email functionality has been removed.type RegisterDiscountProps = { domain: string; durationInDays: number; discountId: string; customMessage: string; priceInEth: bigint; - mailGroups: string[]; goBack: () => void; sponsor?: string; };
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (15)
components/discount/freeRegisterCheckout.tsx(2 hunks)components/discount/freeRenewalCheckout.tsx(3 hunks)components/discount/registerDiscount.tsx(3 hunks)components/domains/autorenewal.tsx(4 hunks)components/domains/registerV3.tsx(0 hunks)components/domains/renewalV2.tsx(1 hunks)components/domains/steps/checkoutCard.tsx(3 hunks)components/domains/steps/userInfoForm.tsx(3 hunks)context/FormProvider.tsx(1 hunks)pages/freerenewal.tsx(0 hunks)pages/register/[domainToRegister].tsx(0 hunks)pages/renewal.tsx(1 hunks)pages/subscription.tsx(1 hunks)tests/utils/userDataService.test.js(2 hunks)utils/userDataService.ts(1 hunks)
💤 Files with no reviewable changes (3)
- pages/register/[domainToRegister].tsx
- pages/freerenewal.tsx
- components/domains/registerV3.tsx
🔇 Additional comments (16)
pages/subscription.tsx (1)
11-11: LGTM! Email collection removal properly implemented.
The removal of the groups prop from <AutoRenewal /> aligns with the PR objective of removing email collection functionality.
pages/renewal.tsx (1)
13-13: LGTM! Verify FormProvider context updates.
The removal of the groups prop from <RenewalV2 /> is correct. However, let's verify that the FormProvider context has been updated to remove any email-related state management.
✅ Verification successful
FormProvider context is clean - no email-related state found
After reviewing the FormProvider implementation, I can confirm that there is no email-related state or logic in the context. The form state only manages properties related to NFTs, domains, metadata, and tax information. The removal of the groups prop from <RenewalV2 /> is safe.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check FormProvider implementation for any remaining email-related code
rg -l "email" --type ts --type tsx "context/FormProvider"
Length of output: 83
Script:
#!/bin/bash
# First, let's find the FormProvider file
fd "FormProvider" --type f
# Then check for email-related code in the found files
rg "email" --type ts
Length of output: 1437
Script:
#!/bin/bash
# Let's check the content of FormProvider.tsx specifically
cat context/FormProvider.tsx
Length of output: 3581
utils/userDataService.ts (2)
Line range hint 21-29: LGTM! Hash computation remains secure.
The implementation maintains security best practices:
- Proper use of crypto.subtle for hashing
- Salt-based randomization
- SHA-256 algorithm
18-21: Breaking change: Verify all computeMetadataHash call sites.
The removal of the email parameter from computeMetadataHash is aligned with the PR objectives. However, this is a breaking change that requires careful verification:
- All call sites must be updated to use the new signature
- Hash values will be different for existing data due to the modified input format
✅ Verification successful
All computeMetadataHash call sites have been properly updated
Based on the verification results:
- All call sites (
FormProvider.tsx,autorenewal.tsx,registerDiscount.tsx,freeRenewalCheckout.tsx,freeRegisterCheckout.tsx) are using the new two-parameter signature correctly - The test cases have been updated to match the new signature
- No residual email-related code exists in
userDataService.ts - The only email-related code in utils is in
stringService.ts, which is unrelated to this change
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Find all calls to computeMetadataHash to ensure they've been updated
echo "Searching for computeMetadataHash usage..."
ast-grep --pattern 'computeMetadataHash($$$)'
# Look for any remaining email-related code in nearby files
echo "Checking for any missed email-related code..."
rg -l "email" --type ts --type tsx "utils/"
Length of output: 1670
Script:
#!/bin/bash
# Search for email-related code in utils directory with proper file type
echo "Checking for any missed email-related code in utils..."
rg -l "email" utils/
# Get the content of userDataService.ts to verify the complete function implementation
echo "Checking userDataService.ts content..."
cat utils/userDataService.ts
# Search for test cases to verify the changes
echo "Checking test cases..."
rg -A 5 "computeMetadataHash" tests/utils/userDataService.test.js
Length of output: 2075
components/domains/renewalV2.tsx (1)
14-14: LGTM! Verify complete removal of email functionality
The component changes align with the PR objective of removing email collection. The removal of the groups prop and email-related code simplifies the component while maintaining core renewal functionality.
✅ Verification successful
Let me check the context of these remaining email occurrences to ensure they're not related to the removed email collection functionality.
Email functionality has been properly removed
The remaining occurrences of "email" are just API payload defaults where "none" is used as a value, indicating that email collection has been properly removed from the user interface and form handling. These occurrences are part of the API contract and don't represent any remaining email collection functionality.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Verify no remaining email-related code in renewal components
rg -i "email" components/domains/
Length of output: 160
Script:
#!/bin/bash
# Check the context of remaining email occurrences
rg -i "email" components/domains/autorenewal.tsx -B 2 -A 2
rg -i "email" components/domains/steps/checkoutCard.tsx -B 2 -A 2
Length of output: 506
tests/utils/userDataService.test.js (1)
Line range hint 62-78: LGTM! Test updates correctly reflect metadata hash changes
The test case has been properly updated to reflect the removal of email from metadata hash computation while maintaining security and correctness of the hash calculation.
✅ Verification successful
Test updates correctly reflect the implementation of metadata hash computation
The verification confirms that:
- The test file accurately matches the implementation in
userDataService.ts - Both the implementation and test only use
taxStateandsaltparameters - The hash computation logic is consistent between test and implementation
- No email-related metadata computation exists in the codebase
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Verify complete removal of email from metadata computation
rg -i "email.*metadata" .
Length of output: 27
Script:
#!/bin/bash
# Let's search for metadata-related code to verify the changes
rg -l "metadata" .
Length of output: 657
Script:
#!/bin/bash
# Search for any remaining email references in hash computation
ast-grep --pattern 'function computeMetadataHash($_) { $$$ }'
Length of output: 63
Script:
#!/bin/bash
# Check the test file content for better context
cat tests/utils/userDataService.test.js
Length of output: 3284
Script:
#!/bin/bash
# Let's check the implementation of computeMetadataHash
rg -A 5 "export.*computeMetadataHash" .
Length of output: 393
Script:
#!/bin/bash
# Check for any previous versions or references to email in metadata hash
git log -p --all -S "computeMetadataHash.*email"
Length of output: 0
Script:
#!/bin/bash
# Check the implementation file directly
cat utils/userDataService.ts
Length of output: 1230
context/FormProvider.tsx (2)
46-48: Style: Minor formatting improvements
The spacing after arrow functions has been standardized.
Line range hint 7-22: LGTM! FormState properly updated
The FormState type has been correctly updated to remove email-related fields while maintaining all necessary state management for tax and metadata purposes.
✅ Verification successful
Email fields have been properly removed from FormState and related components
Based on the verification results:
- The FormState type in FormProvider.tsx no longer contains any email-related fields
- The form-related components (userInfoForm, swissForm, transferFormModal) don't contain any email field implementations
- Remaining email references in the codebase are unrelated to the form state:
- Newsletter-related functionality in
/pages/newsletter - Email validation utilities in
/utils/stringService.ts - Test files for email validation
- "Email" connector name in wallet integration
- Newsletter-related functionality in
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Verify complete removal of email from form state and context
rg -i "email" context/
Length of output: 22
Script:
#!/bin/bash
# Let's verify if there are any email-related fields or usages in the entire codebase
# This will help ensure the removal was complete across the application
rg -i "email" .
Length of output: 3073
Script:
#!/bin/bash
# Let's also check the git diff to see what was removed
git diff HEAD~1 -- context/FormProvider.tsx
Length of output: 45
Script:
#!/bin/bash
# Let's check for any form-related components that might still reference email
fd -e tsx -e ts form
Length of output: 174
Script:
#!/bin/bash
# Let's check the content of form-related components to ensure no email fields remain
cat components/domains/steps/userInfoForm.tsx components/domains/swissForm.tsx components/identities/actions/transferFormModal.tsx
Length of output: 11945
Script:
#!/bin/bash
# Let's also check for any email-related interfaces or types in the codebase
ast-grep --pattern 'interface $_ {
$$$
email
$$$
}'
ast-grep --pattern 'type $_ = {
$$$
email
$$$
}'
Length of output: 116
components/domains/steps/userInfoForm.tsx (1)
94-96: LGTM! Button text logic simplified.
The button text logic has been appropriately simplified after removing email validation checks.
components/discount/freeRegisterCheckout.tsx (1)
109-109: LGTM! Email parameter removed from metadata hash.
The metadata hash computation has been correctly updated to remove the email parameter.
components/domains/steps/checkoutCard.tsx (2)
167-167: LGTM! Email hardcoded to "none" in metadata.
The email field has been correctly hardcoded to "none" in the metadata, aligning with the PR objective to remove email collection.
246-247: LGTM! Improved formatting and simplified conditions.
The code formatting and condition simplification improve readability while maintaining the same functionality.
Also applies to: 313-314
components/domains/autorenewal.tsx (2)
111-114: LGTM: Clean email removal implementation
The metadata handling has been correctly updated to use a hardcoded "none" for email, aligning with the PR objectives.
378-381: LGTM: Improved button text clarity
The button text changes provide clearer feedback to users about the subscription status and requirements.
components/discount/freeRenewalCheckout.tsx (2)
204-204: LGTM: Minor changes
The dependency array update and button text formatting changes look good.
Also applies to: 321-322
96-96: Verify metadata structure compatibility
The email field is now hardcoded to "none" in the metadata submission. While this aligns with removing email collection, we should verify that the sales server API (/add_metadata) properly handles this default value.
✅ Verification successful
Hardcoded email value "none" is consistently used across the codebase
The verification shows that all checkout components (autorenewal.tsx, checkoutCard.tsx, registerDiscount.tsx, and freeRenewalCheckout.tsx) consistently use the same hardcoded value "none" for the email field in metadata submissions, indicating this is an established pattern across the codebase. This change aligns with the broader initiative to remove email collection while maintaining API compatibility.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check if the sales server API validates the "none" email value
# Search for email validation in the sales server API
rg -A 5 "add_metadata" --type ts --type js
# Check for any email validation patterns
ast-grep --pattern 'email: $_'
Length of output: 2042
fricoben
force-pushed
the
ref/delete-mail
branch
from
6197b2f to
da3630e
Compare
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Outside diff range and nitpick comments (6)
components/domains/autorenewal.tsx (2)
112-112: LGTM with a suggestion for future improvementThe hardcoding of email as "none" in metadata handling is a clean way to remove email collection while maintaining compatibility with existing systems. However, consider creating a follow-up task to remove the email field from the backend API entirely.
Consider creating a technical debt ticket to:
- Remove the email field from the backend API schema
- Update the metadata structure to exclude email-related fields
- Clean up any email-related database columns
Also applies to: 152-158
379-382: Fix indentation for consistencyWhile the button text messages are clear and appropriate, the indentation is inconsistent with the rest of the file.
Apply this formatting fix:
- ? "Select a domain to subscribe" - : callData.length === 0 - ? "You're already subscribed" - : "Enable subscription"} + ? "Select a domain to subscribe" + : callData.length === 0 + ? "You're already subscribed" + : "Enable subscription"}components/discount/registerDiscount.tsx (1)
Line range hint
29-37: Remove unused mailGroups propSince email functionality has been removed, the
mailGroupsprop should be removed from theRegisterDiscountPropstype and the component's parameter list.type RegisterDiscountProps = { domain: string; durationInDays: number; discountId: string; customMessage: string; priceInEth: bigint; - mailGroups: string[]; goBack: () => void; sponsor?: string; };context/FormProvider.tsx (1)
Line range hint
1-130: Consider documenting the metadata hash formatSince we're making a significant change to how metadata is handled (removing email), it would be helpful to add documentation about the expected format of the metadata hash and what
"none"signifies in this context.useMemo(() => { if (!formState.salt || !formState.needMetadata) return; (async () => { + // Metadata hash format: hash(email="none", country="switzerland"|"none", salt) + // "none" is used as a placeholder since email collection has been removed updateFormState({ metadataHash: await computeMetadataHash( "none", formState.isSwissResident ? "switzerland" : "none", formState.salt as string ), }); })(); }, [components/discount/freeRenewalCheckout.tsx (1)
96-96: Consider using a constant for the default email valueThe hardcoded string "none" is used as a default email value. Consider defining this as a constant to maintain consistency and make future updates easier.
+ const DEFAULT_EMAIL = "none"; - email: "none", + email: DEFAULT_EMAIL,components/domains/steps/userInfoForm.tsx (1)
Line range hint
116-126: Clean up unnecessary whitespaceWhile the email field removal and SwissForm implementation look good, there's unnecessary whitespace that could be removed to improve code readability.
- - {formState.needMetadata ? ( + {formState.needMetadata ? (
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (14)
components/discount/freeRegisterCheckout.tsx(2 hunks)components/discount/freeRenewalCheckout.tsx(3 hunks)components/discount/registerDiscount.tsx(3 hunks)components/domains/autorenewal.tsx(4 hunks)components/domains/registerV3.tsx(0 hunks)components/domains/renewalV2.tsx(1 hunks)components/domains/steps/checkoutCard.tsx(3 hunks)components/domains/steps/userInfoForm.tsx(3 hunks)context/FormProvider.tsx(2 hunks)pages/freerenewal.tsx(0 hunks)pages/register/[domainToRegister].tsx(0 hunks)pages/renewal.tsx(1 hunks)pages/subscription.tsx(1 hunks)tests/utils/userDataService.test.js(1 hunks)
💤 Files with no reviewable changes (3)
- pages/freerenewal.tsx
- pages/register/[domainToRegister].tsx
- components/domains/registerV3.tsx
🚧 Files skipped from review as they are similar to previous changes (5)
- pages/subscription.tsx
- pages/renewal.tsx
- tests/utils/userDataService.test.js
- components/discount/freeRegisterCheckout.tsx
- components/domains/steps/checkoutCard.tsx
🔇 Additional comments (12)
components/domains/autorenewal.tsx (1)
49-49: LGTM: Clean removal of unused props type
The removal of SubscriptionProps type aligns with the PR objective of removing email functionality, as the component no longer needs to accept any props.
components/discount/registerDiscount.tsx (3)
110-116: LGTM: Email parameter correctly hardcoded
The metadata hash computation has been updated to use a hardcoded "none" value for email, which aligns with the removal of email collection functionality.
Line range hint 290-294: Remove unused mailGroups parameter
While email has been correctly set to "none", the mailGroups parameter is still being sent in the request body despite the removal of email functionality.
body: JSON.stringify({
meta_hash: metadataHash,
email: "none",
- groups: mailGroups, // Domain Owner group
tax_state: isSwissResident ? "switzerland" : "none",
salt: salt,
}),398-405: LGTM: Button validation logic updated
The button's disabled condition has been correctly updated to remove email validation while maintaining all other necessary checks.
context/FormProvider.tsx (2)
46-46: LGTM: Minor formatting changes
The formatting changes to the empty arrow functions are consistent with the codebase style.
Also applies to: 48-48
104-107: Verify the impact of hardcoding email to "none"
The change to use "none" as a hardcoded email value aligns with the PR objective to remove email collection. However, we should verify that:
- This change is consistent across all components using
computeMetadataHash - The metadata hash computation remains valid with this hardcoded value
✅ Verification successful
Based on the results, I can now generate the final response:
Hardcoded email value "none" is consistently used across the codebase
The verification confirms that:
- All calls to
computeMetadataHashacross the codebase consistently use"none"as the email parameter - No email state management types were found in the codebase
- The function signature in
utils/userDataService.tsstill accepts email as a parameter, but this is acceptable for backward compatibility
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Verify consistent email removal across codebase
# Check for any remaining email-related computeMetadataHash calls
echo "Checking for remaining email-related metadata hash computations..."
rg -A 3 "computeMetadataHash"
# Check for any remaining email state management
echo "Checking for remaining email state management..."
ast-grep --pattern 'email: string'
Length of output: 4444
components/domains/renewalV2.tsx (1)
14-14: LGTM: Props removal aligns with email removal objective
The removal of the groups prop from RenewalV2 component aligns with the PR objective of removing email collection functionality. The component maintains its core renewal flow functionality while eliminating unnecessary email-related props.
components/discount/freeRenewalCheckout.tsx (2)
322-323: LGTM: Clear user guidance in button text
The button text provides clear guidance for domain selection, maintaining good UX despite the removal of email-related functionality.
197-205: 🛠️ Refactor suggestion
Simplify metadata hash computation parameters
The metadata hash computation still includes the email parameter even though it's hardcoded. Consider refactoring the computeMetadataHash function to remove the email parameter entirely since it's no longer needed.
✅ Verification successful
Remove unused email parameter from computeMetadataHash function
The verification confirms that while computeMetadataHash accepts an email parameter, all current usages in the codebase pass "none" as the email argument. The function implementation shows that email is only used as part of the message string for hashing. Since it's consistently passed as "none", the parameter can be safely removed.
utils/userDataService.ts: Remove theemailparameter from thecomputeMetadataHashfunction and update its implementation to use onlytaxStateandsalt- Update the following files to remove the "none" argument:
components/domains/autorenewal.tsxcontext/FormProvider.tsxcomponents/discount/freeRenewalCheckout.tsxcomponents/discount/registerDiscount.tsxcomponents/discount/freeRegisterCheckout.tsxtests/utils/userDataService.test.js
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check if computeMetadataHash is used elsewhere with email parameter
ast-grep --pattern 'computeMetadataHash($_email, $_, $_)'
Length of output: 59
Script:
#!/bin/bash
# Let's first find the computeMetadataHash function definition
ast-grep --pattern 'const computeMetadataHash = $_'
# Also search for any usage of computeMetadataHash
rg "computeMetadataHash" -A 2
Length of output: 3343
Script:
#!/bin/bash
# Let's check the actual implementation of computeMetadataHash function
cat utils/userDataService.ts
Length of output: 1254
components/domains/steps/userInfoForm.tsx (3)
Line range hint 1-19: LGTM! Import statements are clean and aligned with changes
The removal of email-related imports is consistent with the PR objectives.
94-97: LGTM! Button text logic properly simplified
The function maintains essential domain selection validation while removing unnecessary email-related checks.
Line range hint 1-168: Verify FormContext cleanup
While the component changes look good, we should verify that the FormContext has been properly updated to remove email-related state.
✅ Verification successful
FormContext has been properly cleaned up
The FormContext implementation has been verified and shows no traces of email-related state. The FormState type and initialState object are clean, containing only the necessary fields for domain registration and renewal (isSwissResident, tokenId, durationInYears, selectedDomains, metadata fields, etc.). The email field has been completely removed from the context.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for any remaining email-related code in FormContext
rg -i "email" "context/FormProvider"
# Check for any remaining email-related types or interfaces
ast-grep --pattern 'interface $_ {
$$$
email
$$$
}'
Length of output: 155
Script:
#!/bin/bash
# Try to find FormProvider/FormContext files in the repository
fd -t f "FormProvider|FormContext"
# Search for any email-related code in the entire codebase
rg -i "email.*formcontext|formcontext.*email"
# Search for FormContext imports to locate the file
rg "FormContext"
Length of output: 1362
Script:
#!/bin/bash
# Check the content of FormProvider.tsx to verify email-related state
cat context/FormProvider.tsx
Length of output: 3599
fricoben
added
🔥 Ready for review
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Outside diff range and nitpick comments (1)
components/domains/steps/checkoutCard.tsx (1)
232-236: Consider enhancing type safety for button text.The function handles validation states well, but could benefit from type safety improvements.
Consider this type-safe implementation:
- const getButtonText = () => { + const getButtonText = (): string => { if (!termsBox) return "Please accept terms & policies"; if (invalidBalance) return `You don't have enough ${displayedCurrency}`; return "Purchase"; };
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (3)
components/discount/freeRegisterCheckout.tsx(3 hunks)components/domains/steps/checkoutCard.tsx(4 hunks)tests/utils/userDataService.test.js(0 hunks)
💤 Files with no reviewable changes (1)
- tests/utils/userDataService.test.js
🚧 Files skipped from review as they are similar to previous changes (1)
- components/discount/freeRegisterCheckout.tsx
🔇 Additional comments (2)
components/domains/steps/checkoutCard.tsx (2)
252-253: LGTM: Formatting improvement.
The condition refinement improves readability while maintaining the same logic.
316-316: LGTM: Clean implementation of button text.
The button text implementation correctly uses the helper function.
| @@ -166,7 +164,7 @@ const CheckoutCard: FunctionComponent<CheckoutCardProps> = ({ | |||
| headers: { "Content-Type": "application/json" }, | |||
| body: JSON.stringify({ | |||
| meta_hash: formState.metadataHash, | |||
| email: formState.email, | |||
| email: "none", | |||
There was a problem hiding this comment.
💡 Codebase verification
Found additional email-related code that needs attention
There are still instances of email-related code in other components that should be reviewed for consistency:
components/domains/autorenewal.tsx: Containsemail: "none"components/discount/freeRenewalCheckout.tsx: Containsemail: "none"components/discount/registerDiscount.tsx: ContainsmailGroupsprop and usage, along withemail: "none"
🔗 Analysis chain
LGTM: Email removal aligns with PR objectives.
The hardcoded "none" value maintains API compatibility while removing email collection.
Let's verify no other email-related code remains:
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for any remaining email-related code
rg -i 'email|mail' --type ts --type tsx
Length of output: 69
Script:
#!/bin/bash
# Search for any remaining email-related code, using ripgrep without file type filters
rg -i 'email|mail' components/
Length of output: 503
close #932 I tested that the add_metadata still works on
/renewal.I'll let you make some E2E tests also (the reviewer) on another page.
Summary by CodeRabbit
Release Notes
New Features
Bug Fixes
Chores