What is the reason of exposing only accountId, but not entire ConnectedWalletAccount?

[karpovdmitryod]

During the migration to WalletSelector, we faced the fact that you are not exposing ConnectedWalletAccount object.

Due to this, many functionalities available before switching to WalletSelected are no longer accessible.
e.g - you just recently added the possibility to get a user signature
another example - we cannot create a new Contract instance, and we are now rewriting everything to RPC calls.

What was the reason for not exposing this object to the end users?

[austinabell]

Curious about this too. Is the intended pattern that Wallet is used along with a signer account id string?

[grachyov]

Exposing near-api-js types would make it necessary to inject near-api-js or it's parts.

[karpovdmitryod]

Exposing near-api-js types would make it necessary to inject near-api-js or it's parts.

but near-api-js are already part of wallet selector dependencies.
In our case, migration caused the additional effort

1. no way to instantiate Contract instance, we had to rewrite everything to RPC calls
2. no way to access Keystore, and get public key and the user signature. Current verifyOwner implementation feat: Add Support for verifyOwner #391 for my near wallet requires interaction with the wallet for some reasons, and this breaks our UI experience.

[grachyov]

but near-api-js are already part of wallet selector dependencies.

Injected scripts do not have direct access to these dependencies.

[amirsaran3]

@karpovdmitryod Not all wallets use the ConnectedWalletAccount interface. We only expose the accountId since all wallets expose at least that.

If you have any other questions feel free to reopen this issue.

[pharaouk]

No updates on this.....? Very bad design to not allow for full ConnectedWalletAccount object......