refactor: prepare removing /display request on every page load#564
Merged
refactor: prepare removing /display request on every page load#564
/display request on every page load#564Conversation
theborakompanioni
added
the
refactoring
dergigi
approved these changes
Nov 17, 2022
Contributor
dergigi
left a comment
dergigi
left a comment
There was a problem hiding this comment.
Looks good to me, tACK ✅
Good job cleaning up some of the naming as well, it's much clearer now! ✨ 👏
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
In preparation of #356.
Note: The commits of this PR are included in the follow-up PR #566 - you can either review them separately or just review #566.
This PR prepares removing the
/displayAPI request on every page load./displayis a rather expensive request and only needed if 1) the status of an address is requested ('new' | 'used' | 'reused' | 'cj-out' | 'change-out' | 'non-cj-change' | 'deposit') or 2) address-reuses should be checked (which is generally a bit "flawed") or 3) a "new" address is chosen without calling "newaddress" (can be replaced with generating a new address).This is currently only the case in the
JarDetailsoverlay, pagesSendandSweepor when creating a Fidelity Bond and can be loaded on demand rather than on every page load.First step in this preparation is to remove to
totalBalanceandavailableBalanceproperties from theWalletInforequest. Instead,calculatedTotalBalanceandcalculatedAvailableBalanceare used, which use their input data from the more lightweight/utxoresponse.Also, on a side note,
/displayalso returns the actual amount of "accounts" (Jars) - there will be a need to load the data once after unlocking and reload only after an impactful action has been triggered.