Change Details

Cashtab does not have fine-grained tx update ability. It should (and for other things) ... 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 this was originally designed, that was fine, because we did not even have websockets. But now websockets can and should drive pretty much everything. - 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. - 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. It should (and for other things) ...When we need to update one tx, but that will require sqlite across platforms and a migrationwe 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, When this was originally designedand, that was finewith the android app, because we did not even have websockets.we should start optimizing storage and app speed using a database to enhance caching and updates. In this diff, But now websockets can and should drive pretty much everythingwe 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.