Change Details

Cashtab does not have fine-grained tx update ability. When we need to update one tx, we need to update the whole state of the app. This should be fixed ... but that will require sqlite across platforms and a migration. Cashtab's key-value storage needs async updating. We update the whole state when we update a utxo or a tx in history. When Cashtab was originally designed, this was acceptable, because we did not even have websockets (let alone strongly typed utxos and other libs). But now websockets can and should drive pretty much everything, and, with the android app, we should start optimizing storage and app speed using a database to enhance caching and updates. In this diff, we do what we can to optimize state updates without changing the key-value storage. - Clean up websocket initialization; we need to `useRef` to make sure we are always using the current state. Previously we did this by re-initializing the websocket with the latest param whenever the param changed. This was okay when the websocket only mattered on blockheight change or fiat price change. But this can't work when we need to sometimes make multiple state changes for the same incoming ws event (e.g. a block finalizes and 5 txs also finalize). So we `useRef` - Queue async methods that are triggered by ws msgs - For finalized txs in particular, batch these updates. This is esp important now as finalization only occurs with postconsensus, so the user often has many txs finalize at the same time.

Cashtab does not have fine-grained tx update ability. When we need to update one tx, we need to update the whole state of the app. This should be fixed ... but that will require sqlite across platforms and a migration. Cashtab's key-value storage needs async updating. We update the whole state when we update a utxo or a tx in history. When Cashtab was originally designed, this was acceptable, because we did not even have websockets (let alone strongly typed utxos and other libs). But now websockets can and should drive pretty much everything, and, with the android app, we should start optimizing storage and app speed using a database to enhance caching and updates. In this diff, we do what we can to optimize state updates without changing the key-value storage. - We introduce `useRef` instead of passing state vars as params. Avoided this because ... useRef is a complication, and it did not matter so much when we really only had to worry about the price updating every 90s. But now that cashtabState can change on every tx, it does not make sense at all to re-initialize websockets every time there is a state change. We need to useRef so functions have access to the current state, and not the state that existed when the function was first initialized (this is a quirk of React that was previously handled by passing params and re-initializing functions with useEffect). - Queue async methods that are triggered by ws msgs (we can have race conditions with multiple onMessage calls trying to update the same state with different inputs) - Batch finalized updates. This is esp important now as finalization only occurs with postconsensus, so the user often has many txs finalize at the same time. Async queueing may not totally resolve this as we cannot `await` react state changes.

Cashtab does not have fine-grained tx update ability. When we need to update one tx, we need to update the whole state of the app. This should be fixed ... but that will require sqlite across platforms and a migration. Cashtab's key-value storage needs async updating. We update the whole state when we update a utxo or a tx in history. When Cashtab was originally designed, this was acceptable, because we did not even have websockets (let alone strongly typed utxos and other libs). But now websockets can and should drive pretty much everything, and, with the android app, we should start optimizing storage and app speed using a database to enhance caching and updates. In this diff, we do what we can to optimize state updates without changing the key-value storage. - Clean up websocket initialization;- We introduce `useRef` instead of passing state vars as params. we need to `useRef` to make sure we are always using the current stateAvoided this because ... Previously we did this by re-initializing the websocket with the latest param whenever the param changed.useRef is a complication, This was okay when the websocketand it did not matter so much when we really only mattered on blockheight change or fiat price changehad to worry about the price updating every 90s. But this can't work when we need to sometimes make multiple state changes for the same incoming ws event (e.gnow that cashtabState can change on every tx, it does not make sense at all to re-initialize websockets every time there is a state change. a block finalizes and 5 txs also finalize).We need to useRef so functions have access to the current state, So we `useRef`and not the state that existed when the function was first initialized (this is a quirk of React that was previously handled by passing params and re-initializing functions with useEffect). - Queue async methods that are triggered by ws msgs - For finalized txs in particular, (we can have race conditions with multiple onMessage calls trying to update the same state with different inputs) - Batch finalized updates. batch these updates.This is esp important now as finalization only occurs with postconsensus, This is esp important now aso the user often has many txs finalization only occurs with postconsensus,e at the same time. so the user often has many txs finalize at the same timeAsync queueing may not totally resolve this as we cannot `await` react state changes.