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

Add support for custom chains in changeNetwork function #425

Open
wants to merge 10 commits into
base: main
Choose a base branch
from

Conversation

arjanjohan
Copy link

Current Situation:

The changeNetwork function does not support custom networks because the chainId cannot be inferred from the network name.

Fix:

This PR introduces an optional customChainId parameter to the changeNetwork function in WalletCore.ts. The parameter is only used when switching to a custom chain.

Additionally, I have updated both wallet-adapter-react and wallet-adapter-vue to pass this optional parameter when calling the changeNetwork function.

Tests:

I updated apps/nextjs-example, and it now supports switching between both custom and predefined networks. However, I did not update apps/nuxt-example as I have limited experience with Nuxt, and network switching in that example already appears to be broken.

Copy link
Collaborator

@0xmaayan 0xmaayan left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the contribution! Overall LGTM, left some comments

packages/wallet-adapter-react/src/WalletProvider.tsx Outdated Show resolved Hide resolved
@@ -39,7 +39,7 @@ export interface WalletContextState {
): Promise<PendingTransactionResponse>;
signMessage(message: SignMessagePayload): Promise<SignMessageResponse>;
signMessageAndVerify(message: SignMessagePayload): Promise<boolean>;
changeNetwork(network: Network): Promise<AptosChangeNetworkOutput>;
changeNetwork(network: Network, chainId?: number): Promise<AptosChangeNetworkOutput>;
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Lets let the user pass in the chainId as a string, and have the adapter do the parsing before sending it to the wallet

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I know in the example used in this repo, the chainId is provided in an input field and using string would make sense. However, I believe this to be an exceptional case. I imagina all dApps that will utilize this feature will handle the logic in the backend, and the chainId is not provided by the user but rather from some backend storage where it's stored as number.

Let me know what you think.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see. I'd argue that they will be retrieving it from an API query, where it will mostly be in a string format. Instead of requiring the dapp to convert it to a number, the adapter can handle that conversion for them.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That makes sense, thanks for clarifying. I will modify it and push the changes.

Copy link
Collaborator

@0xmaayan 0xmaayan left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please run changeset to include this change in the next release

packages/wallet-adapter-vue/src/composables/useWallet.ts Outdated Show resolved Hide resolved
@@ -39,7 +39,7 @@ export interface WalletContextState {
): Promise<PendingTransactionResponse>;
signMessage(message: SignMessagePayload): Promise<SignMessageResponse>;
signMessageAndVerify(message: SignMessagePayload): Promise<boolean>;
changeNetwork(network: Network): Promise<AptosChangeNetworkOutput>;
changeNetwork(network: Network, chainId?: number): Promise<AptosChangeNetworkOutput>;
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see. I'd argue that they will be retrieving it from an API query, where it will mostly be in a string format. Instead of requiring the dapp to convert it to a number, the adapter can handle that conversion for them.

Copy link
Collaborator

@0xmaayan 0xmaayan left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks! LGTM.
Only two comments are left to address, and then we can merge.

apps/nextjs-example/src/app/page.tsx Outdated Show resolved Hide resolved
@arjanjohan
Copy link
Author

Thanks! LGTM. Only two comments are left to address, and then we can merge.

I processed the comments and updated the example nextJS app.

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

Successfully merging this pull request may close these issues.

2 participants