Change Details

A new 'Reply To Message' option on the transaction history tab for each inbound OP_RETURN message transaction. When clicking on the Reply To Message option, it takes the user to the Send page where the address is pre-populated with the original message sender's address, the minimum 5.5 XEC for the message tx and the Message input field opened by default. * The parseTxData function in useBCH.js is updated to extract the first vin address as the original sender's address and encodes it into an eCash address, before adding it to the parsedTx object as 'replyAddress'. * Tx.js has a new <Link> component added which encapsulates the Reply To Message label. This component routes to the '/send' path whilst also passing 'data.replyAddress' to the Send page. * Send.js checks for the existence of location.state.replyAddress within useEffect() and if found, it prepopulates the address field with the replyAddress and the XEC value field with the minimum 5.5. The <AdvancedCollapse> defaultActiveKey property is also set to 1 (opened) so the Message input field is opened by default if it's a message reply, and set to 0 (closed) otherwise. * The prepopulation of address/value UX is streamlined for the user to just focus on typing out their reply and hit send assuming they have enough balance. In extension mode, the user is taken directly to the Message input field without needing to scroll down. This diff supersedes D10495. The most recent feedback from @bytesofman in D10495 were: * validateDOMNesting warning about nested <a> in browser console - this is because the Reply To Message <Link> needs to be rendered within the existing <TxWrapper>, which evaluates out to a nested <a> link in the browser. I couldn't see a way around this because otherwise it's hard to keep it in visual sync within the Transaction card. * Brave browser - I've tested this all ok with Version 1.32.113 Chromium: 96.0.4664.45 (Official Build) (64-bit) on ubuntu. Url field is intended to look standard as the reply address is passed through internal state (lines 413-417 in Tx.js) which is then picked up upon useEffect() (lines 150-155) in Send.js

A new 'Reply To Message' option on the transaction history tab for each inbound OP_RETURN message transaction. When clicking on the Reply To Message option, it takes the user to the Send page where the address is pre-populated with the original message sender's address, the minimum 5.5 XEC for the message tx and the Message input field opened by default. * The parseTxData function in useBCH.js is updated to extract the first vin address as the original sender's address and encodes it into an eCash address, before adding it to the parsedTx object as 'replyAddress'. * Tx.js has a new <Link> component added which encapsulates the Reply To Message label. This component routes to the '/send' path whilst also passing 'data.replyAddress' to the Send page. * Send.js checks for the existence of location.state.replyAddress within useEffect() and if found, it prepopulates the address field with the replyAddress and the XEC value field with the minimum 5.5. The <AdvancedCollapse> defaultActiveKey property is also set to 1 (opened) so the Message input field is opened by default if it's a message reply, and set to 0 (closed) otherwise. * The prepopulation of address/value UX is streamlined for the user to just focus on typing out their reply and hit send assuming they have enough balance. In extension mode, the user is taken directly to the Message input field without needing to scroll down. This diff supersedes D10495. The most recent feedback from @bytesofman in D10495 were: * validateDOMNesting warning about nested <a> in browser console - this is because the Reply To Message <Link> needs to be rendered within the existing <TxWrapper>, which evaluates out to a nested <a> link in the browser. I couldn't see a way around this because otherwise it's hard to keep it in visual sync within the Transaction card. * Brave browser - I've tested this all ok with Version 1.32.113 Chromium: 96.0.4664.45 (Official Build) (64-bit) on ubuntu. Url field is intended to look standard as the reply address is passed through internal state (lines 413-417 in Tx.js) which is then picked up upon useEffect() (lines 150-155) in Send.js {F5182842}

A new 'Reply To Message' option on the transaction history tab for each inbound OP_RETURN message transaction. When clicking on the Reply To Message option, it takes the user to the Send page where the address is pre-populated with the original message sender's address, the minimum 5.5 XEC for the message tx and the Message input field opened by default. * The parseTxData function in useBCH.js is updated to extract the first vin address as the original sender's address and encodes it into an eCash address, before adding it to the parsedTx object as 'replyAddress'. * Tx.js has a new <Link> component added which encapsulates the Reply To Message label. This component routes to the '/send' path whilst also passing 'data.replyAddress' to the Send page. * Send.js checks for the existence of location.state.replyAddress within useEffect() and if found, it prepopulates the address field with the replyAddress and the XEC value field with the minimum 5.5. The <AdvancedCollapse> defaultActiveKey property is also set to 1 (opened) so the Message input field is opened by default if it's a message reply, and set to 0 (closed) otherwise. * The prepopulation of address/value UX is streamlined for the user to just focus on typing out their reply and hit send assuming they have enough balance. In extension mode, the user is taken directly to the Message input field without needing to scroll down. This diff supersedes D10495. The most recent feedback from @bytesofman in D10495 were: * validateDOMNesting warning about nested <a> in browser console - this is because the Reply To Message <Link> needs to be rendered within the existing <TxWrapper>, which evaluates out to a nested <a> link in the browser. I couldn't see a way around this because otherwise it's hard to keep it in visual sync within the Transaction card. * Brave browser - I've tested this all ok with Version 1.32.113 Chromium: 96.0.4664.45 (Official Build) (64-bit) on ubuntu. Url field is intended to look standard as the reply address is passed through internal state (lines 413-417 in Tx.js) which is then picked up upon useEffect() (lines 150-155) in Send.js {F5182842}