feat: allow resetting qrcode #605
Conversation
📝 WalkthroughWalkthroughThe changes introduce a "send another payment" feature to the PaymentDialog component. A new customizable Changes
Sequence DiagramsequenceDiagram
actor User
participant PaymentDialog
participant WidgetContainer
participant Widget
User->>PaymentDialog: Click "Send Another Payment" button
activate PaymentDialog
PaymentDialog->>PaymentDialog: handleSendAnother() increments resetKey
PaymentDialog->>WidgetContainer: Pass resetKey prop
deactivate PaymentDialog
activate WidgetContainer
WidgetContainer->>WidgetContainer: useEffect detects resetKey change
WidgetContainer->>WidgetContainer: Reset success & shiftCompleted flags
WidgetContainer->>Widget: Re-initialize with fresh state
deactivate WidgetContainer
activate Widget
Widget->>Widget: Ready for new payment
deactivate Widget
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes Suggested labels
Suggested reviewers
Poem
🚥 Pre-merge checks | ✅ 2 | ❌ 1❌ Failed checks (1 inconclusive)
✅ Passed checks (2 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing touches
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![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
🤖 Fix all issues with AI agents
In `@react/lib/components/PaymentDialog/PaymentDialog.tsx`:
- Around line 158-162: The handleSendAnother function currently clears timers
and resets success/resetKey but leaves the parent altpaymentShift state stale;
update handleSendAnother to also call setAltpaymentShift(undefined) so
altpaymentShift is cleared before starting a new payment flow (add alongside
clearAutoCloseTimer, setSuccess(false), setResetKey(...)); this ensures
subsequent payments don't inherit previous altpaymentShift values and avoids
incorrect pair/shift initialization.
In `@react/lib/components/Widget/WidgetContainer.tsx`:
- Around line 166-171: The resetKey effect currently clears success and shift
completion but not the stored payment identifier; update the useEffect that
watches resetKey to also call the state setter for thisPaymentId (e.g.,
setThisPaymentId(undefined)) when resetKey !== undefined && resetKey > 0 so a
fresh payment ID is generated for the next flow; keep the existing
setSuccess(false) and setShiftCompleted(false) behavior.
| const handleSendAnother = (): void => { | ||
| clearAutoCloseTimer(); | ||
| setSuccess(false); | ||
| setResetKey(prev => prev + 1); | ||
| }; |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Check altpaymentShift usage in WidgetContainer
echo "=== altpaymentShift in WidgetContainer ==="
rg -n 'altpaymentShift' react/lib/components/Widget/WidgetContainer.tsxRepository: PayButton/paybutton
Length of output: 335
🏁 Script executed:
#!/bin/bash
# Check altpaymentShift usage in Widget
echo "=== altpaymentShift in Widget ==="
rg -n 'altpaymentShift' react/lib/components/Widget/Widget.tsxRepository: PayButton/paybutton
Length of output: 306
🏁 Script executed:
#!/bin/bash
# Check if altpaymentShift is a state variable and how it's initialized
echo "=== altpaymentShift definition and usage ==="
rg -n 'setAltpaymentShift|useState.*altpaymentShift' react/lib/components/Widget/Repository: PayButton/paybutton
Length of output: 1005
🏁 Script executed:
#!/bin/bash
# Check PaymentDialog to see if it manages altpaymentShift
echo "=== altpaymentShift in PaymentDialog ==="
rg -n 'altpaymentShift' react/lib/components/PaymentDialog/PaymentDialog.tsxRepository: PayButton/paybutton
Length of output: 214
🏁 Script executed:
#!/bin/bash
# Check PaymentDialog props interface to see all props it receives
echo "=== PaymentDialog props interface ==="
rg -n -A20 'interface PaymentDialogProps' react/lib/components/PaymentDialog/PaymentDialog.tsxRepository: PayButton/paybutton
Length of output: 730
🏁 Script executed:
#!/bin/bash
# Check where PaymentDialog is instantiated to see what props are passed
echo "=== PaymentDialog usage in Widget ==="
rg -n -B3 -A8 'PaymentDialog' react/lib/components/Widget/Widget.tsx | head -50Repository: PayButton/paybutton
Length of output: 100
🏁 Script executed:
#!/bin/bash
# Check what props are passed to PaymentDialog at line 1101
echo "=== PaymentDialog props passed from Widget ==="
sed -n '1095,1115p' react/lib/components/Widget/Widget.tsxRepository: PayButton/paybutton
Length of output: 1082
🏁 Script executed:
#!/bin/bash
# Get full PaymentDialogProps interface
echo "=== Complete PaymentDialogProps interface ==="
sed -n '9,80p' react/lib/components/PaymentDialog/PaymentDialog.tsxRepository: PayButton/paybutton
Length of output: 2042
🏁 Script executed:
#!/bin/bash
# Check where PaymentDialog is called in Widget to see all props passed
echo "=== PaymentDialog instantiation in Widget ==="
rg -n -B5 -A30 '<PaymentDialog' react/lib/components/Widget/Widget.tsx | head -80Repository: PayButton/paybutton
Length of output: 108
🏁 Script executed:
#!/bin/bash
# Check PaymentDialog component destructuring to confirm setAltpaymentShift is extracted
echo "=== PaymentDialog component destructuring ==="
sed -n '90,150p' react/lib/components/PaymentDialog/PaymentDialog.tsxRepository: PayButton/paybutton
Length of output: 1490
🏁 Script executed:
#!/bin/bash
# Verify complete handleSendAnother function and surrounding context
echo "=== handleSendAnother function and context ==="
sed -n '155,165p' react/lib/components/PaymentDialog/PaymentDialog.tsxRepository: PayButton/paybutton
Length of output: 365
🏁 Script executed:
#!/bin/bash
# Check what happens when altpaymentShift is reset - look at usage pattern
echo "=== How altpaymentShift state affects re-initialization ==="
rg -n -B3 -A3 'altpaymentShift' react/lib/components/PaymentDialog/PaymentDialog.tsxRepository: PayButton/paybutton
Length of output: 847
Reset altpaymentShift in handleSendAnother to avoid stale shift data on subsequent payments.
When a user clicks "Send Another Payment" after an altpayment transaction, the altpaymentShift state persists at the parent level. This causes the next payment to initialize with stale shift data, potentially causing incorrect pair selection or shift initialization.
Add setAltpaymentShift(undefined) to handleSendAnother:
Suggested change
const handleSendAnother = (): void => {
clearAutoCloseTimer();
setSuccess(false);
+ setAltpaymentShift(undefined);
setResetKey(prev => prev + 1);
};📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| const handleSendAnother = (): void => { | |
| clearAutoCloseTimer(); | |
| setSuccess(false); | |
| setResetKey(prev => prev + 1); | |
| }; | |
| const handleSendAnother = (): void => { | |
| clearAutoCloseTimer(); | |
| setSuccess(false); | |
| setAltpaymentShift(undefined); | |
| setResetKey(prev => prev + 1); | |
| }; |
🤖 Prompt for AI Agents
In `@react/lib/components/PaymentDialog/PaymentDialog.tsx` around lines 158 - 162,
The handleSendAnother function currently clears timers and resets
success/resetKey but leaves the parent altpaymentShift state stale; update
handleSendAnother to also call setAltpaymentShift(undefined) so altpaymentShift
is cleared before starting a new payment flow (add alongside
clearAutoCloseTimer, setSuccess(false), setResetKey(...)); this ensures
subsequent payments don't inherit previous altpaymentShift values and avoids
incorrect pair/shift initialization.
| useEffect(() => { | ||
| if (resetKey !== undefined && resetKey > 0) { | ||
| setSuccess(false); | ||
| setShiftCompleted(false); | ||
| } | ||
| }, [resetKey]); |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
# First, examine the WidgetContainer.tsx file to understand state declarations
wc -l react/lib/components/Widget/WidgetContainer.tsxRepository: PayButton/paybutton
Length of output: 182
🏁 Script executed:
# Get the state declarations and useEffect hook in question
head -200 react/lib/components/Widget/WidgetContainer.tsx | tail -150Repository: PayButton/paybutton
Length of output: 4297
🏁 Script executed:
# Search for thisPaymentId usage in the file
rg -n 'thisPaymentId' react/lib/components/Widget/WidgetContainer.tsx -A 2 -B 2Repository: PayButton/paybutton
Length of output: 767
🏁 Script executed:
# Search for altpaymentShift usage
rg -n 'altpaymentShift|setAltpaymentShift' react/lib/components/Widget/WidgetContainer.tsx -A 2 -B 2Repository: PayButton/paybutton
Length of output: 982
🏁 Script executed:
# Search for currencyObj usage and initialization
rg -n 'currencyObj|setCurrencyObj' react/lib/components/Widget/WidgetContainer.tsx -A 2 -B 2Repository: PayButton/paybutton
Length of output: 1744
🏁 Script executed:
# Look for any existing reset logic or patterns for payment resets
rg -n 'reset|Reset' react/lib/components/Widget/WidgetContainer.tsx -A 2 -B 2Repository: PayButton/paybutton
Length of output: 552
🏁 Script executed:
# Find the Widget component to understand paymentId usage
fd -e tsx -e ts Widget.tsx | grep -v node_modules | head -5Repository: PayButton/paybutton
Length of output: 150
🏁 Script executed:
# Search for where paymentId is generated or used in payment verification
rg -n 'setThisPaymentId|setInternalPaymentId|new.*[Pp]aymentId|generatePaymentId|paymentId.*=' react/lib/components/Widget/ -A 2 -B 2Repository: PayButton/paybutton
Length of output: 1972
🏁 Script executed:
# Check if altpaymentShift comes from parent state management
rg -n 'setAltpaymentShift' react/lib/components/ -B 3 -A 1 | head -40Repository: PayButton/paybutton
Length of output: 2990
🏁 Script executed:
# Understand the transaction flow - where does paymentId get used for tracking
rg -n 'thisPaymentId' react/lib/components/ -B 2 -A 2Repository: PayButton/paybutton
Length of output: 1727
🏁 Script executed:
# Check how Widget component handles paymentId generation
rg -n 'setPaymentId\|generatePaymentId' react/lib/components/Widget/Widget.tsx -B 3 -A 3Repository: PayButton/paybutton
Length of output: 45
🏁 Script executed:
# Look at the larger context of the resetKey useEffect - understand what happens after reset
sed -n '165,200p' react/lib/components/Widget/WidgetContainer.tsxRepository: PayButton/paybutton
Length of output: 1227
🏁 Script executed:
# Check if there are other resetKey patterns or payment flow resets elsewhere
rg -n 'setSuccess\|setShiftCompleted' react/lib/components/Widget/WidgetContainer.tsx -B 2 -A 2Repository: PayButton/paybutton
Length of output: 45
🏁 Script executed:
# Understand if internalPaymentId auto-resets or if it persists across attempts
rg -n 'internalPaymentId\|internalAltpayment' react/lib/components/Widget/Widget.tsx -B 2 -A 2Repository: PayButton/paybutton
Length of output: 45
🏁 Script executed:
# Search for where setPaymentId is called to understand payment ID generation
rg -n 'setPaymentId\|setThisPaymentId' react/lib/components/ -A 1 -B 1 | head -60Repository: PayButton/paybutton
Length of output: 45
🏁 Script executed:
# Look at Widget component's payment ID handling
sed -n '180,220p' react/lib/components/Widget/Widget.tsxRepository: PayButton/paybutton
Length of output: 1697
🏁 Script executed:
# Search for payment ID generation logic
rg -n 'uuid\|generateId\|crypto.*random\|Math\.random' react/lib/components/Widget/ | head -20Repository: PayButton/paybutton
Length of output: 45
🏁 Script executed:
# Check the Widget component structure around line 338 where setPaymentId callback is passed
sed -n '330,350p' react/lib/components/Widget/WidgetContainer.tsxRepository: PayButton/paybutton
Length of output: 571
🏁 Script executed:
# Search for where setPaymentId is actually used in Widget
rg -n 'setPaymentId' react/lib/components/Widget/Widget.tsx -B 2 -A 2Repository: PayButton/paybutton
Length of output: 1224
🏁 Script executed:
# Check how payment ID flows through - find where it's generated
rg -n 'paymentId.*uuid\|paymentId.*=\|paymentId.*function' react/lib/components/Widget/ -A 2Repository: PayButton/paybutton
Length of output: 45
🏁 Script executed:
# Look for form generation or payment ID creation logic
rg -n 'createUnsignedTx\|createTxOutput\|getPaymentAddress' react/lib/components/Widget/Widget.tsx -B 1 -A 3 | head -50Repository: PayButton/paybutton
Length of output: 45
🏁 Script executed:
# Check the complete context around the Widget component props/usage
sed -n '300,345p' react/lib/components/Widget/WidgetContainer.tsxRepository: PayButton/paybutton
Length of output: 1566
🏁 Script executed:
# Check if payment ID reset happens elsewhere or if there are comments about payment flow
rg -n 'payment.*reset\|reset.*payment' react/lib/components/Widget/ -iRepository: PayButton/paybutton
Length of output: 45
🏁 Script executed:
# Look at the larger context around line 641 to understand payment ID generation flow
sed -n '630,670p' react/lib/components/Widget/Widget.tsxRepository: PayButton/paybutton
Length of output: 1062
🏁 Script executed:
# Check if updateConvertedCurrencyObj context shows when payment ID is reset
sed -n '315,330p' react/lib/components/Widget/Widget.tsxRepository: PayButton/paybutton
Length of output: 1014
Consider resetting thisPaymentId when resetKey triggers to avoid reusing the same payment ID.
When a payment attempt completes and resetKey increments to trigger a new payment flow, the thisPaymentId should be reset to undefined so that a fresh payment ID is generated. Currently, the same payment ID persists across multiple payment attempts, which could cause tracking issues. The Widget component already resets the payment ID when currency changes (line 322-324 in Widget.tsx), so it should also reset when the user explicitly triggers a new payment via resetKey.
Note: altpaymentShift is a parent-managed prop and doesn't require reset here. The currencyObj appears to auto-derive from amount and currency changes.
🤖 Prompt for AI Agents
In `@react/lib/components/Widget/WidgetContainer.tsx` around lines 166 - 171, The
resetKey effect currently clears success and shift completion but not the stored
payment identifier; update the useEffect that watches resetKey to also call the
state setter for thisPaymentId (e.g., setThisPaymentId(undefined)) when resetKey
!== undefined && resetKey > 0 so a fresh payment ID is generated for the next
flow; keep the existing setSuccess(false) and setShiftCompleted(false) behavior.
Related to #280
Description
Implement send another payment option after a payment is complete
Test plan
Make a payment, click in Send Another Payment and do another payment, make sure everything works smoothly
Summary by CodeRabbit
✏️ Tip: You can customize this high-level summary in your review settings.