Conversation
packages/widget-provider-solana/src/providers/SolanaProviderValues.tsx
Outdated
Show resolved
Hide resolved
tomiiide
force-pushed
the
LF-13181-chore-upgrade-solana-provider
branch
2 times, most recently
from
79c22a0 to
25196a1
Compare
tomiiide
force-pushed
the
LF-13181-chore-upgrade-solana-provider
branch
from
52703bf to
5b0f257
Compare
packages/widget-provider-solana/src/wallet-standard/wallet-standard-store.ts
Outdated
Show resolved
Hide resolved
packages/widget-provider-solana/src/providers/SolanaProvider.tsx
Outdated
Show resolved
Hide resolved
packages/widget-provider-solana/src/wallet-standard/useSolanaWalletStandard.ts
Outdated
Show resolved
Hide resolved
|
Hey! This is your new endpoint: https://bc4709bc.widget-lf13181cho.pages.dev |
| try { | ||
| await select(walletName) | ||
| if (accountAddress) { | ||
| onSuccess?.(accountAddress, ChainId.SOL) | ||
| } | ||
| } catch (error) { | ||
| console.error('Failed to connect wallet:', error) |
There was a problem hiding this comment.
Did a bit more testing and analysis on this PR, found some issues.
There is a race condition here: after await select(walletName) completes, accountAddress in the closure is stale, it reflects the value before the connection. The onSuccess callback receives null or the old address instead of the newly connected address.
There was a problem hiding this comment.
Good catch.
- I've renamed the
selectfunction toconnectto be more accurate. - I've updated the function to return directly the address after connection.
| ) | ||
|
|
||
| if (targetWallet && !state.connected) { | ||
| state.select(persistedWalletName, { |
There was a problem hiding this comment.
The select() call returns a Promise, but it's not awaited, so if a silent connect fails, the promise rejection goes unhandled.
There was a problem hiding this comment.
Good catch here, it's now awaited.
|
Hey! This is your new endpoint: https://0842067a.widget-lf13181cho.pages.dev |
3 participants
Which Jira task is linked to this PR?
https://lifi.atlassian.net/browse/LF-13181
Related to lifinance/sdk#327
Why was it implemented this way?
Explain the reasoning behind the implementation. Were there alternative approaches? Why was this solution chosen?
Since
SDKSolanaProvideronly deals withTransactiontypes from@solana/kit, the widget still uses web3.js, we have convert the transaction types.Visual showcase (Screenshots or Videos)
If applicable, attach screenshots, GIFs, or videos to showcase the functionality, UI changes, or bug fixes.
Checklist before requesting a review