Change Details

T2207 Upgrade Cashtab tx parsing to support all known OP_RETURN lokads and token tx types

T2207 T3405 Upgrade Cashtab tx parsing to support all known OP_RETURN lokads and token tx types This is another tech debt fix. Tx parsing grew incrementally and was never rebuilt to accomodate many different tx types. Instead, each new type was shimmed in. Now that we have react testing library, we can handle and test most of the rendering logic in the actual component render. Imo this is the better place to do it. At a certain point, human readable "parsed" keys are pretty silly to be storing in the wallet state. So, `parseTx` is refactored to return only some calculated values from a Tx_InNode. We could lose the function entirely, but it is useful to preserve the existing unit tests so we know we are getting the same behavior (well, we can tell the behavior is changing as we expect, where we expect). All of the rendering logic is handled in `Tx/index.js`, which is tested according to what the tx's look like to the user and not a large collection of JSON values as previous. We stop using a shimmed antd Collapse which saves us another ~75ish kb on the bundle size. Icons from https://thenounproject.com/ paid account. Feature changes - Every tx is parsed as an XEC tx on the first line - Every OP_RETURN gets an App Action, a row under the XEC tx info. EMPP is not yet supported, but, when it is supported, we can support multiple App Actions. The code is already set up to handle these as an array. - Every token action gets its own row. We do not test this (yet) with large ALP txs, as this diff is big enough already. But, same logic -- any tx can have several different token actions. The previous approach of "guess which seems to be the main thing, and then just render that" -- has clear shortcomings. This is a better way to present information to normal users and power users alike. Similar to what you see at etherscan. - Most actions get their own icons. - All txs are "to" or "from" an address or contact. We assume txs are from inputs[0].outputScript. If a tx is "to" multiple addresses -- for now we just assume it is to the first outputScript that is not an input of the tx. This can be optimized later (mb we pick the one who received the "most"), but will always need to make some kind of assumption unless you just render everything that is happening. - We now add a "to" address to contacts

T2207 T3405 Upgrade Cashtab tx parsing to support all known OP_RETURN lokads and token tx types This is another tech debt fix. Tx parsing grew incrementally and was never rebuilt to accomodate many different tx types. Instead, each new type was shimmed in. Now that we have react testing library, we can handle and test most of the rendering logic in the actual component render. Imo this is the better place to do it. At a certain point, human readable "parsed" keys are pretty silly to be storing in the wallet state. So, `parseTx` is refactored to return only some calculated values from a Tx_InNode. We could lose the function entirely, but it is useful to preserve the existing unit tests so we know we are getting the same behavior (well, we can tell the behavior is changing as we expect, where we expect). All of the rendering logic is handled in `Tx/index.js`, which is tested according to what the tx's look like to the user and not a large collection of JSON values as previous. We stop using a shimmed antd Collapse which saves us another ~75ish kb on the bundle size. Icons from https://thenounproject.com/ paid account. Feature changes - Every tx is parsed as an XEC tx on the first line - Every OP_RETURN gets an App Action, a row under the XEC tx info. EMPP is not yet supported, but, when it is supported, we can support multiple App Actions. The code is already set up to handle these as an array. - Every token action gets its own row. We do not test this (yet) with large ALP txs, as this diff is big enough already. But, same logic -- any tx can have several different token actions. The previous approach of "guess which seems to be the main thing, and then just render that" -- has clear shortcomings. This is a better way to present information to normal users and power users alike. Similar to what you see at etherscan. - Most actions get their own icons. - All txs are "to" or "from" an address or contact. We assume txs are from inputs[0].outputScript. If a tx is "to" multiple addresses -- for now we just assume it is to the first outputScript that is not an input of the tx. This can be optimized later (mb we pick the one who received the "most"), but will always need to make some kind of assumption unless you just render everything that is happening. - We now add a "to" address to contacts