-
Notifications
You must be signed in to change notification settings - Fork 252
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
feature: WalletProvider #569
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
makes sense, only have some naming suggestions
crates/provider/src/wallet.rs
Outdated
/// Get a reference to the underlying signer. | ||
fn signer(&self) -> &Self::Signer; | ||
|
||
/// Get a mutable reference to the underlying signer. | ||
fn signer_mut(&mut self) -> &mut Self::Signer; | ||
|
||
/// Get the default signer address. | ||
fn default_signer(&self) -> Address { | ||
self.signer().default_signer() | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
hmm, perhaps naming could be confusing here.
default_signer
vs signer
perhaps we should include _address
in the fn name?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I want to rename NetworkSigner
to NetworkWallet
, and LocalWallet
to LocalSigner
, and always use Wallet
to mean "a collection of credentials" and signer to mean "a single credential". but that is a more extensive refactor
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
opened a new issue #575
7bf36b5
to
f407b5d
Compare
* feature: WalletProvider * feature: signer_mut * test: a basic one * test: bubbles up * refactor: renames for clarity
Adds a trait that allows users to access the
NetworkSigner
in a signing fill + provider stack.Motivation
Allow users to view keys and add signing credentials after building the provider stack.
Solution
Add a trait that exposes the underlying signer via borrows and mut borrows, and includes convenience functions for the useful
NetworkSigner
functionsNote:
This trait is implemented only when both of the following are true:
R
filler on the joinfill,These conditions are true for all stacks constructed by the builder. This is a bit non-intuitive, but is necessary to avoid conflicting impls when both L and R are signer provider and when multiple signers are present in a stack. While neither of those cases are expected ever, the type system allows for them. Therefore we cannot neatly describe this trait without the assumptions above
PR Checklist