-
Notifications
You must be signed in to change notification settings - Fork 191
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
feat: holistic custom recipient address part 2 #6072
Conversation
Current dependencies on/for this PR:
This stack of pull requests is managed by Graphite. |
@@ -64,7 +64,7 @@ export const ManualAddressEntry: FC = memo((): JSX.Element | null => { | |||
// If we have a valid manual receive address, set it in the form | |||
useEffect(() => { | |||
manualReceiveAddress && setFormValue(SendFormFields.Input, manualReceiveAddress) | |||
}, [dispatch, manualReceiveAddress, setFormValue]) | |||
}, [manualReceiveAddress, setFormValue]) |
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 was not needed but somehow not caught by the linter
src/components/MultiHopTrade/components/TradeInput/components/ManualAddressEntry.tsx
Outdated
Show resolved
Hide resolved
9e440d6
to
23bf07f
Compare
src/components/MultiHopTrade/components/TradeConfirm/ReceiveSummary.tsx
Outdated
Show resolved
Hide resolved
src/components/MultiHopTrade/components/TradeInput/components/ManualAddressEntry.tsx
Outdated
Show resolved
Hide resolved
const isYatSupported = isYatFeatureEnabled && isYatSupportedByReceiveChain | ||
const { | ||
formState: { isValidating, isValid }, | ||
// trigger: formTrigger, // TODO(gomes): do we need this? |
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.
Question for @0xApotheosis since this bit was taken from the previous custom receive address component
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'm going to go with "No" - I don't remember this guy's story, but I suspect it can go.
tradeQuoteStep?.source === THORCHAIN_LONGTAIL_STREAMING_SWAP_SOURCE && | ||
_isSmartContractReceiveAddress !== false | ||
) | ||
return true |
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.
might also need to update
src/state/apis/swapper/helpers/validateTradeQuote.ts
-> disableSmartContractSwap
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.
Nice catch, will tackle 🙏🏽 also noticed we've apparently broken the smart contract checks in https://github.com/shapeshift/web/pull/5971/files#diff-b6f4d6672824399e71740531e3b09efe3ad3fabeb3ad6c4ce0763969f9d39ab7R210, will author a hotfix in the meantime (see receiveAddress
vs. senderAddress
)
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.
- Restacked on top of fix: regression of smart contract sell address checks on validateTradeQuote #6081
- Added receive side checks and additional comments in 639cd28
- made this PR relate to Block smart contract receive addresses for SwapOut longtails #5805 instead of closing it while at it, since we cannot yet test this until L1 -> EVM long-tails are implemented in Add L1 to Ethereum long-tail swaps #5892
@@ -351,77 +290,7 @@ export const ReceiveSummary: FC<ReceiveSummaryProps> = memo( | |||
</Row> | |||
</> | |||
)} | |||
|
|||
{/* TODO(gomes): This should probably be made its own component and <ManualAddressEntry /> removed */} | |||
{/* TODO(gomes): we can safely remove this condition when this feature goes live */} |
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.
🐐
src/components/MultiHopTrade/components/TradeInput/components/RecipientAddress.tsx
Outdated
Show resolved
Hide resolved
src/components/MultiHopTrade/components/TradeInput/components/RecipientAddress.tsx
Outdated
Show resolved
Hide resolved
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.
Code wise looks good apart from 1 blocking comment. Will need to test thoroughly when back online
2a8f818
to
4a3e2e5
Compare
4a3e2e5
to
639cd28
Compare
Cross-account issue captured in #6121 |
@0xApotheosis while this is still in draft for the prod issue noted above, this has been fixed in 74b9250: Screen.Recording.2024-02-02.at.12.18.33.movAlso actioned the streaming swap longtail source comment in 7228126 This is ready to be retested, but can't be merged until the prod issue is tackled. |
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.
❌ THORSwap trades now seem broken (see comment inline)
✅ Check mark is now disabled when no valid address entered.
❌ "Preview Trade" button is not disabled when no address is present (e.g. when entering a custom receive address, before pressing the green check to save it). Pressing "Preview Trade" at this time throws an exception:
if ( | ||
[firstHop.source, secondHop.source].some(source => | ||
[THORCHAIN_LONGTAIL_SWAP_SOURCE, THORCHAIN_LONGTAIL_STREAMING_SWAP_SOURCE].includes(source), | ||
) && | ||
_isSmartContractReceiveAddress !== 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.
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.
That one was actually quite the rabbit-hole!
tl;dr of what's up here is we had absolutely no type-safety on steps.length
which could (according to types) be of any n-length, and in the specific case of THOR, secondHop
was defined here.
Fixed this by bringing in the context of single and multi-hop trade quotes, the former consisting of 1 step, the latter consisting of 2 (for now, as we only have a max. of two hops here).
This now brings type errors which should've been present before e.g in here - 1bbd41a
Also fixed the something went very wrong
error in 60b5672 - we got too safe here as there are always going to be at least two renders without a receive address as things are loading
After bringing in safety (and removing the wrong one for receiveAddress checks), THOR is now happy:
- with regular swaps and default receive address
- with streaming swaps and
vitalik.eth
injected wallet
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.
🤔 Probably not a blocker, as we no longer crash in this state, but we still don't ensure the "Preview Trade" button is disabled whilst manually editing the address
✅ THORChain trades are great again
✅ Manual receive address works as expected when manually input
✅ Correct default (synced) address used as default
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 reverts commit c0982e5.
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.
Re-stamp after revert.
Description
Adds custom recipient address support holistically, regardless of whether or not the currently connected wallet does/not support the receive chain
Pull Request Type
Issue (if applicable)
Risk
High. While this is theoretically still under flag and there may be another PR to improve things visually, and another to turn the flag on which will give us another chance to test this, eng. and ops should assume this is going directly to production with no flag.
Testing
^Note WRT the above: this shouldn't be an issue as the custom recipient will be used to get a quote, so instead of producing bugs, this will simply limit the amount of available swappers when using an ENS address (because the missing swappers do not support it, hence do not yield a quote)
Engineering
Operations
Screenshots (if applicable)
Invalid address
Default wallet address
Custom recipient valid address input
Set custom recipient
<img width="787" alt="Screenshot 2024-01-24 at 23 34 27" src="https://github.com/shapeshift/web/assets/17035424/3db140d9-8153-4ef7-83ff-c897d22c0ddd"
Setting an ENS as custom recipient works and restricts the available swappers on swappers supporting it
Screen.Recording.2024-01-24.at.23.41.02.mov
1inch account 0 sell address, ETH account 1 as custom recipient
Li.Fi account 0 sell address, ETH account 1 as custom recipient
Random DOGE address with no balance as custom recipient
Wallet not supporting the receive asset
Screen.Recording.2024-01-25.at.00.07.50.mov
Flag off
Screen.Recording.2024-01-25.at.00.07.50.mov