client/{asset,core}: wallet notifications #2492
Conversation
| // stakeInfo, err := dcr.wallet.StakeInfo(dcr.ctx) | ||
| // if err != nil { | ||
| // dcr.log.Errorf("Error getting stake info for tip change notification data: %v", err) | ||
| // } else { | ||
| // data = &struct { | ||
| // TicketPrice uint64 `json:"ticketPrice"` | ||
| // }{ | ||
| // TicketPrice: uint64(stakeInfo.Sdiff), | ||
| // } | ||
| // } | ||
| dcr.emit.TipChange(uint64(height), data) |
There was a problem hiding this comment.
I leave this here as a demonstration of how wallets can use these to convey asset-customized info when needed. Another use case is for asynchronous ticket purchasing, which may be necessary when mixing is enabled (or even for unmixed tickets, possibly). The StakeInfo method isn't added in this PR, but it is in the gui staking PR #2482.
client/asset/interface.go
Outdated
| } | ||
|
|
||
| // Errorf formats and sends an AsyncWalletErrorNote. | ||
| func (e *WalletEmitter) Errorf(s string, a ...interface{}) { |
There was a problem hiding this comment.
Instead of only Errorf, a general Logf note with an error level argument would be useful to let core know the severity of the notification to send to the front end.
There was a problem hiding this comment.
Did you have a particular place you were thinking it was needed, because I was thinking of removing Errorf and Error altogether. The only thing Core does is log it, and the wallet already has a logger that logs to the same place but with more context. We can add Logf or anything else as needed, but I don't have a use for it right now.
There was a problem hiding this comment.
Yeah it's definitely not needed yet.
buck54321
force-pushed
the
wallet-notes
branch
from
6b8c166
to
0f5a439
Compare
buck54321
force-pushed
the
wallet-notes
branch
from
0f5a439
to
7ee151e
Compare
Gives wallets a way to issue asynchronous notifications. Replaces the
TipChangefunction. These notifications are sent to the front end, but are not used yet. This will help solve some issues that were raised in #2482, but it's also just a better pattern than the tip change function and should enable more up-to-date information on the front end.