-
Notifications
You must be signed in to change notification settings - Fork 99
feat: verifiedAddresses in public API interface #635
Conversation
| addressDetails: address.details, | ||
| } | ||
| }), | ||
| verifiedAddresses: [], |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For now, this will just be an empty response.
| @@ -1,3 +1,8 @@ | |||
| /* eslint-disable import/no-cycle -- | |||
| Cycle between this file and types/verifiedAddress.ts. Should we combine these into one? | |||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Currently we have a types file for verified addresses, and one for the public API.
The other two type files are database types.
I'm thinking that the verified addresses types, and public api types, are really all just protocol types.
I'm thinking we should combine these into one file like (types/protocol.ts or types/address.ts). This would require a bit of a refactor to all the references to previous types files, so I would do that as a subsequent PR.
What do you think?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ya I'm into that, these have been calling for a refactor for a minute now
| }, | ||
| }, | ||
| ], | ||
| verifiedAddresses: [], |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Updates a bunch of tests so they continue to pass.
0xASK
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
| @@ -1,3 +1,8 @@ | |||
| /* eslint-disable import/no-cycle -- | |||
| Cycle between this file and types/verifiedAddress.ts. Should we combine these into one? | |||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ya I'm into that, these have been calling for a refactor for a minute now
High Level Overview of Change
Add
verifiedAddressfield toPaymentInformation.Update Public API interface to adhered to updated
PaymentInformationtype.Update tests so they continue to pass with the expanded interface.
Context of Change
The goal of this PR is to add
verifiedAddressesto the type definition, and tosubsequently update all places in the code so they code compiles & tests
continue to pass.
Type of Change
Before / After
Before:
PaymentInformationdoes not containverifiedAddressesAfter:
PaymentInformationcontainsverifiedAddressesTest Plan
This PR updates all tests so they continue to pass.
I will add any necessary new tests in a subsequent PR.