You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As per title, I am looking to understand the rationale behind this choice, which looks like a limitation to me.
I am building an app that should allow other custom signers and I see no reason why this should be a limitation for the use of react hooks.
Hey @valerioleo! yea good question, we made this choice as it simplifies the initial assumptions that have to be made in supporting a useAccountHook because the account is typed based on the passed in signer. Our initial iteration was to limit the scope of supported signers in the react hooks + ui components to the alchemy signer, but we are evaluating ways to make this more configurable in the future
Hey @valerioleo! yea good question, we made this choice as it simplifies the initial assumptions that have to be made in supporting a useAccountHook because the account is typed based on the passed in signer. Our initial iteration was to limit the scope of supported signers in the react hooks + ui components to the alchemy signer, but we are evaluating ways to make this more configurable in the future
@moldy530 is there any roadmap we can refer to to know when the scope of signers will be expanded?
As per title, I am looking to understand the rationale behind this choice, which looks like a limitation to me.
I am building an app that should allow other custom signers and I see no reason why this should be a limitation for the use of react hooks.
aa-sdk/account-kit/core/src/types.ts
Line 24 in 687c254
The text was updated successfully, but these errors were encountered: