Skip to content
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

Allow usage of predefined UI packages without @solana/wallet-adapter-react dependency #818

Open
toteto opened this issue Aug 9, 2023 · 3 comments

Comments

@toteto
Copy link

toteto commented Aug 9, 2023

Is your feature request related to a problem? Please describe.

I am a developer who would like to utilize the predefined UI packages in Solana, such as material-ui, without necessarily depending on and using wallet-adapter-react. This desire stems from the need to implement custom wallet connection logic while still maintaining a consistent user experience across Solana applications by using standard Solana UI.

Describe the solution you'd like

  • Create a new package for each UI framework that doesn't rely on wallet-adapter-react (e.g., material-ui-base, ant-ui-base, etc.).
  • In these base packages, modify the components to receive required parameters as props, instead of utilizing hooks.
    • For the WalletDialog component, accept wallets: Wallet[] and select: (wallet: Wallet) => void as props.
    • Apply the above modification to the button components as well.
  • In the existing package (the non-base one), import the base package and replace the current component with the one defined in the base. Utilize existing hooks for the props.

Describe alternatives you've considered

  • Using a community-maintained TS implementation like solana-connect - a solid approach, but not on par with the official UI packages.
  • Implementing our solution - a temporary measure until this issue is resolved. This approach is less desirable as it will require continuous updates to align with future changes to the UI.

Additional context

At Mailchain, we have a specific need for this feature, stemming from our handling of multiple protocols. We've designed an abstraction layer that unifies all protocol wallets under a common interface, implemented outside the React package as pure TS. Utilizing the wallet-adapter-react library within this abstraction requires complicated workarounds, hence the need for a more flexible solution.

@jordaaash
Copy link
Collaborator

Hmm. Can you help me understand why you don't want to use the wallet-adapter-react package?

@jordaaash
Copy link
Collaborator

If it's specifically about the connection logic, that's all opt-in. By default autoConnect is falsy, so you can not pass the autoConnect prop on the WalletProvider, or you can pass a function to it now which allows custom handling (used by SIWS).

@toteto
Copy link
Author

toteto commented Aug 9, 2023

Hmm. Can you help me understand why you don't want to use the wallet-adapter-react package?

Thanks for your quick response. I did try to address this in the Additional context section, but I'm happy to elaborate

Our wallet connection logic is implemented as a pure TypeScript (TS) abstraction (no React involved), and React is layered on top of this, consuming it. The need for our own wallet connector abstraction arises from the fact that our application has to support multiple protocols, each with its own wallets and methods. While wallet-adapter-react is an excellent library when only Solana as a protocol needs to be supported, our requirement to handle multiple protocols necessitates a more abstract approach.

Integrating wallet-adapter-react outside the React component tree, in our specific scenario, becomes complex and cumbersome due to its design for use strictly within the React tree. For instance, using the useWallet hook outside of a React component would entail including the WalletProvider within our React tree and then crafting intricate logic to forward the useWallet hook's results into our custom wallet connector abstraction.

I hope this additional explanation clarifies both our need for an abstraction and the challenges of using wallet-adapter-react in our specific context. If there's an approach that I may have overlooked, which could enable us to leverage wallet-adapter-react without these complexities, I'd be eager to hear your thoughts. Thank you!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants