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

Report of WalletAccounts tests #1060

Open
PhilippeR26 opened this issue Apr 3, 2024 · 6 comments
Open

Report of WalletAccounts tests #1060

PhilippeR26 opened this issue Apr 3, 2024 · 6 comments
Labels
Type: bug Something isn't working

Comments

@PhilippeR26
Copy link
Collaborator

Context

I have ended the tests of WalletAccount .
I have some comments :

  • Both in wallet.ts and account.ts, there are methods to subscribe to an event, but there is nothing to unsubscribe.
  • 2 events are subscribed in the constructor of WalletAccount class, but as there is no destructor in Typescript, what are the consequences for the DAPP and for the wallet to create / get out of scope many times WalletAccount instances?
  • Starknet.js is supposed to simplify the work of the devs, but I consider that the methods about events are not really useful, as it's easier to handle events directly with the swo (StarknetWindowObject) :
    With Starknet.js :
myAccountWallet?.onAccountChange(handleAccount);
// or
if (!!swo) {
    wallet.onAccountChange(swo, handleAccount);
}

Directly with the swo :

swo?.on("accountsChanged", handleAccount);
// then
swo?.off("accountsChanged", handleAccount);

About automatic change of account, the re-initialization of cairoVersion is missing here

// Update Address on change
.
About automatic change of chain, the change of this.chainId without changing the nodeurl is generating a complete mess in the DAPP. I think that if the DAPP accepts to change of chain, it has to propose a Rpc provider for each chain accepted. So, in this spirit, it will be the responsibility of the DAPP to convert a new chainId to a new Rpc provider. I think it will be important in the case of layer 3. So, we could delete setChainId, and replace it by something accepting the RpcProviderOptions as input.

Also one little thing, about the access to the frontend provider : if the DAPP wants to do something with the provider in use in the Wallet Account, it needs :

const txR = await myWalletAccount?.channel.waitForTransaction(txH);

Normally, channel should be hidden to the DAPP devs. Couldn't we have something like :

const txR = await myWalletAccount?.provider.waitForTransaction(txH);

Desktop (please complete the following information):

  • Browser & version [e.g. chrome, safari, webworker] : Chrome v123.0.6312.86
  • Node version [e.g. 16.0.1] v21.7.1
  • Starknet.js version : last next-version commit
  • Network [devnet, testnet] : Sepolia/mainnet
  • Wallets : ArgentX v5.13.5 (22/feb/2024, ID :pgicobkbegddeldhlnnacicgioehkbem ), Braavos 0.0.2 experimental

Additional context
Add any other context about the problem here.

@PhilippeR26 PhilippeR26 added the Type: bug Something isn't working label Apr 3, 2024
@EjembiEmmanuel
Copy link

@PhilippeR26 I'll like to work on this

@PhilippeR26
Copy link
Collaborator Author

Hello,
I think it's already handled by core team (@ivpavici )

@PhilippeR26 PhilippeR26 mentioned this issue Apr 22, 2024
6 tasks
@PhilippeR26
Copy link
Collaborator Author

@tabaktoni
I have a strange error when using WalletAccount.deployAccount() :

Error: Expected valid bigint: 0 < bigint < curve.n

I think that you should override deployAccount method, using UDC.

@PhilippeR26
Copy link
Collaborator Author

Following the last commits of the Wallet API, 2 things have to be implemented :

  • new wallet_supportedWalletApi entry point
  • optional parameter api_version added in most of entry point.
  • We should also consider to have Starknet.js compatible with several Wallet API versions (as for starknet rpc API).

Warning

Currently not open to contributors.

@ivpavici
Copy link
Collaborator

@PhilippeR26 can we close this?

@PhilippeR26
Copy link
Collaborator Author

If you consider that all identified problems are solved, or are minor, or will be solved later, you can close.
Personally, I think that @tabaktoni should dig a little in these subjects.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Type: bug Something isn't working
Projects
None yet
Development

No branches or pull requests

3 participants