Integrate WalletConnect #195
Conversation
to fix iOS build (simulator)
nop33
force-pushed
the
wc
branch
2 times, most recently
from
1096b6a to
ef6e6ae
Compare
nop33
force-pushed
the
wc
branch
2 times, most recently
from
f20bcb6 to
adb61a5
Compare
| <ButtonContainer key={i}>{child}</ButtonContainer> | ||
| ))} | ||
| </View> | ||
| <View style={style}>{children?.map((child, i) => <ButtonContainer key={i}>{child}</ButtonContainer>)}</View> |
There was a problem hiding this comment.
Linting was broken for some reason so after upgrading the eslint related packages, this changes was required (also for next file)
| @@ -174,6 +176,11 @@ const ScreenSectionCentered = styled(ScreenSection)` | |||
| align-items: center; | |||
| ` | |||
|
|
|||
| const TextContainer = styled.View` | |||
| width: 80%; | |||
| border: 0px solid transparent; // This is a hack cause I don't freaking understand why the text doesn't expand | |||
nop33
force-pushed
the
wc
branch
2 times, most recently
from
361eb7a to
69ea4ea
Compare
|
|
||
| const initializeWalletConnectClient = useCallback(async () => { | ||
| try { | ||
| console.log('⏳ INITIALIZING WC CLIENT...') |
There was a problem hiding this comment.
I purposefully left many logs so that we're able to debug everything until the WC integration becomes stable. The logs are mainly before and after each call to WC, and when receiving an event from WC.
nop33
force-pushed
the
wc
branch
2 times, most recently
from
3bcbb5c to
ccafdea
Compare
| export type PendingTransaction = | ||
| | { | ||
| hash: string | ||
| fromAddress: string | ||
| toAddress: string | ||
| timestamp: number | ||
| amount?: string | ||
| tokens?: explorer.Token[] | ||
| lockTime?: number | ||
| status: 'pending' | ||
| type: 'transfer' | ||
| } | ||
| | { | ||
| hash: string | ||
| fromAddress: string | ||
| timestamp: number | ||
| amount?: string | ||
| tokens?: explorer.Token[] | ||
| lockTime?: number | ||
| status: 'pending' | ||
| type: 'call-contract' | ||
| } | ||
| | { | ||
| hash: string | ||
| fromAddress: string | ||
| timestamp: number | ||
| amount?: string | ||
| tokens?: explorer.Token[] | ||
| lockTime?: number | ||
| status: 'pending' | ||
| type: 'deploy-contract' | ||
| } |
There was a problem hiding this comment.
We could probably make this dryer, like:
type CommonPendingTransactionFields = {
hash: string;
fromAddress: string;
timestamp: number;
amount?: string;
tokens?: explorer.Token[];
lockTime?: number;
status: 'pending';
};
type TransferPendingTransaction = CommonPendingTransactionFields & {
toAddress: string;
type: 'transfer';
};
type CallContractPendingTransaction = CommonPendingTransactionFields & {
type: 'call-contract';
};
type DeployContractPendingTransaction = CommonPendingTransactionFields & {
type: 'deploy-contract';
};
export type PendingTransaction =
| TransferTransaction
| CallContractTransaction
| DeployContractTransaction;| @@ -0,0 +1,714 @@ | |||
| /* | |||
There was a problem hiding this comment.
Okay.. I can imagine that this one was pain
There was a problem hiding this comment.
This file seems to be a rather "simple" in terms of code (mostly conditions and state update)... I feel like all we need now is a lot of testing.
| [walletConnectClient] | ||
| ) | ||
|
|
||
| const respondToWalletConnectWithSuccess = async (event: SessionRequestEvent, result: SignResult) => { |
There was a problem hiding this comment.
Why isn't this one wrap in a useCallback call?
There was a problem hiding this comment.
Because it's only used by handleApprovePress which is not used in a dependency array of anything, so there's no need to wrap with a useCallback.
|
Phew, that merge conflict resolution was a pain in the 🍑, mainly because in the meantime we changed the modals from Modalize to our own. Needs a lot of testing. Hopefully we can merge this before we add many things on |
| async (uri: string) => { | ||
| if (!walletConnectClient) return | ||
|
|
||
| const pairingTopic = uri.substring('wc:'.length, uri.indexOf('@')) |
There was a problem hiding this comment.
🤓
Interesting idea the 'wc:'.length to make it more explicit for the reader than just "3"
|
This is some heavy stuff sir |
|
My propositions:
|
It's quite tricky to implement that, I would need to lift the state of the proposal modal up to the context and hack it through, it didn't feel clean at all. Since the modal works well when its content is changed, I'd rather leave it as it is for now (I improved the layout a bit) |
No description provided.