Having looked into it I am not certain I can parse relative links without a protocol unless at the very least, an external library is added. That said even the external libraries I have tested aren't perfect( lists of links separated by commas (ex. google.com, cashtab.com, yahoo.com becomes google.com, cashtab.com, yahoo.com,), if a url is provided that does not support https it cannot really be accounted for, plus some other nits). Let me know if you want to see a version that uses an external library, or if you have any advice for how to improve the functionality here I would appreciate it.

Updated Summary per review feedback.

removed unnecessary test prop from JSONPretty component

updated snapshots

removed test comment

added test comment to trigger snapshot update & rebased to master

Responding to review feedback.

Reduced top and bottom padding of WalletInfoCtn by 10px.

Responding to review feedback

In this diff, I am using the example provided here: https://github.com/HarveyD/react-component-library/compare/master...styled-components. As far as I can tell postcss doesn't run on styled components, though I may be able to find a plugin that will accomplish this if needed.

Responding to review feedback

When sending an encrypted msg, the wallet that sent the encrypted msg repeatedly fires this warning. Tested on a wallet with no recent outgoing encrypted msgs and didn't get the error. I assume this isn't a big deal but wanted to flag it in case it is unexpected behavior.

Updated snapshots.

Responding to review feedback, media queries have been added to lessen the amount of margin on top of the QRCode component when the screen is between 1000px - 320px width.

Wondering why the huksy pre-commit testing didn't catch the snapshot issue, any ideas?

Updated snapshots

Responding to review feedback

updated validValueString error msg to match validAddress

Responding to review feedback. Removed specific address from handleMultiAddressChange validAddress and validValueString error msgs. While this theoretically makes it harder to discern which address has an error, through testing I have learned that in its current state, the DestinationAddressMulti input only fires an error if the first address is invalid, meaning we aren't giving up too much. A task will be created to deal with this issue.

That makes sense. The way it works right now, the error will only fire if the first address is invalid. I would like to look into updating this to highlight the invalid address, regardless of position. I will create a task to look into it for a later diff.

Removed test comment

ran arc diff instead of arc diff HEAD^

Readme is not related to the xec-web-components library. A link to the project scaffolding will be added to the readme in a later update. Readme contains a typo which is causing build issues, which is why it is being removed in this diff, and not a later on in the stack.

Removed content from README as it was irrelevant to the library.