wildmolasses
commented
4 years ago If so, I'm wondering if there is any straightforward way to get a brand new tx added to the list provisionally, even before it's known about by the responding endpoint.
Yes! pursuant to #66, we just need to iterate over wallet.pending.transactions in the UI in order to achieve this. Once we hear about the transaction from an API response, the tx is then removed from wallet.pending.transactions. Should feel pretty clean hopefully.
Resolves #35 Resolves #40 Resolves #47 Resolves #52 Resolves #64
There are 2 parts to this PR. One part is the mocked api calls and related tests. Currently we're using 3 different "state snapshots," each corresponding to a different point in a wallet's life. here's an example of 1 state snapshot. We have some transactions and UTXOs. the next state snapshot changes the state to what it should look like when a transaction is sent (including new change address UTXO/tx), and finally state 3 is what happens when a tx is sent from another wallet to our receive address. Setting this up was the only way I could think of to have more confidence around utxo management, balance movement, receive/change address advancement, and pending tx management.
The other part of this PR is fixing some things that were wrong. We have more reliable balances. sendTx works multiple times in a row (ha). When the wallet sees activity on its current receive address, it will derive a new one. All stuff that was mostly implemented, but needed some tweaking.
Finally I moved the address discovery to just one place, and I made the call to updateState more discerning so we're making the minimum number of api calls. I added a "refresh data" button to the WalletBalance. I removed the obsolete GET block calls from the transaction parsing.