chore(widget-solana-provider): update solana provider to match latest interface #600
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
| skipReady, | ||
| }: { | ||
| client?: Client | ||
| client?: any |
There was a problem hiding this comment.
This expects a viem Client type that was previously re-exported from the sdk.
This re-export was removed from the sdk here
Now, there are three solutions:
- Keep the re-export (simple and easy but feels dirty)
- Add
viemas a dependency towidget-provider(cleaner but increases bundle size for just one type) - Re-architect the widget such that contexts and types are defined in their respective ecosystem provider (Ideal but requires more work)
Leaning towards 3, but I would need to think deeply about the 2nd order effects.
SuiContext should be in sui-provider and be imported by wallet-provider however, we don't want wallet-provider to depend on any of the ecosystem provider.
So how would wallet-provider be aware of other ecosystem contexts without defining and import it ?
I have an idea of wallet-provider having a sdkProvidersStore that other ecosystem providers can import and then register/unregister.
There was a problem hiding this comment.
Why did we drift from our usual naming convention for this one?
| import { type PropsWithChildren, useContext } from 'react' | ||
| import { SolanaBaseProvider } from './SolanaBaseProvider' | ||
| import type { PropsWithChildren } from 'react' | ||
| import { useSolanaWalletStandard } from '../wallet-standard/useSolanaWalletStandard' |
There was a problem hiding this comment.
We should use .js extensions on file imports.
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