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
In #1174 utxos we made a tradeoff against encapsulation of the Account object by passing the utxos from outside without any guarantee on their belonging to the Account concerned. Obviously, the Account should otherwise manage its utxos internally to avoid introducing bugs due to inconsistency of the utxos passed, moreover it's conceptually awkward to persist utxos in the frontend state as part of accountInfo and work with them if the frontend isn't actually dealing with them directly at all.
This was done as a quick fix to the problem that utxos may get out of sync with the transaction history/balance shown to the user in the UI, potentially misleading the user to send successfully the same transaction twice thinking the first transaction didn't acutally get through which is arguably a more serious problem, at least in the short term.
A possible, less fragile solution would be to refactor the Account object to cache the accountInfo/utxos internally and make sure to expose to the UI only a method that would always refresh the cache as the UI gets updated as well
The text was updated successfully, but these errors were encountered:
In #1174 utxos we made a tradeoff against encapsulation of the Account object by passing the utxos from outside without any guarantee on their belonging to the Account concerned. Obviously, the Account should otherwise manage its utxos internally to avoid introducing bugs due to inconsistency of the utxos passed, moreover it's conceptually awkward to persist utxos in the frontend state as part of accountInfo and work with them if the frontend isn't actually dealing with them directly at all.
This was done as a quick fix to the problem that utxos may get out of sync with the transaction history/balance shown to the user in the UI, potentially misleading the user to send successfully the same transaction twice thinking the first transaction didn't acutally get through which is arguably a more serious problem, at least in the short term.
Link to an instance of the "encapsulation antipattern" introduced: 4b9b402#diff-6893a7d215735a9db1543b71624173acf36bc0be3698cbbee3a01c2681fe08c1R51
A possible, less fragile solution would be to refactor the Account object to cache the accountInfo/utxos internally and make sure to expose to the UI only a method that would always refresh the cache as the UI gets updated as well
The text was updated successfully, but these errors were encountered: