[PART 3] Networking Refactor - Add VaultPaymentTokensAPI
#188
Conversation
* Remove Eligibility feature * remove two types for Eligibility feature
* vault without purchase * clean up cardClient initializer * Use associatedType for variables for GraphQLQuery protocol * moving setuptoken call to demo app * use APIRequest for merchantServer setupToken request * use enum for PaymentSourceInput for different payment options * get request for setup token details * move graphQL request, responses from Core to Card module * remove APIRequest use in demo app * Add VaultCardDelegate for VaultCardResult * Add payment token creation in demo app * remove duplicate UpdateSetupTokenQuery.swift * rename UpdateSetupTokenRequest to UpdateSetupTokenQuery * added newly named file reference to project * add mocks for unit tests, pr feedback * disable swiftlint for multiline query, target for card test * correct target for MockGraphQLClient * CardClient vault error tests * docStrings and CHANGELOG * PR feedback * PR feedback * PR feedback nodoc String for GraphQLQuery requestBody() * spacing in paymentTokenRequest * PR feedback * PR feedback from Jax 8/16/23 * PR feedback from Jax cleanup
…r data in GraphQL request types to prevent double encoding
…ype at PPaaSAPI levels
|
See slightly updated class diagram:
|
| @@ -1,5 +1,5 @@ | |||
| /// Used to decode the HTTP reponse body of GraphQL requests | |||
| struct GraphQLHTTPResponse<T: Codable>: Codable { | |||
| /// :nodoc: Used to decode the HTTP reponse body of GraphQL requests | |||
There was a problem hiding this comment.
This has 0 relation to this PR, but I wonder if we should consider DocC first for PPCP. 👀
There was a problem hiding this comment.
We should give it a whirl! We'll run into that same issue of needing to host a landing page for each of our submodules, right? But it would definitely be easier to start with over BT, I agree!
But in terms of nodoc this doesn't actually do anything in PPCP since it isn't set up with Jazzy. We need to write a ticket to update these to @_documentation(visibility: private) so at least things look good in the Xcode generated docs.
There was a problem hiding this comment.
Ticket for this work - DTPPCPSDK-726
There was a problem hiding this comment.
Yeah - it would be a good test for structure/format since we don't have anything currently. We can start fresh with DocC vs switching from Jazzy down the road. 🎉
| return try parseSuccessResult(data, as: T.self) | ||
| } else { | ||
| return try parseErrorResult(data, as: T.self) | ||
| } |
There was a problem hiding this comment.
Is there ever a case where we couldn't parse the data into either an error or success result?
There was a problem hiding this comment.
I went back and forth on the best way to write this file to be as DRY as possible and landed on this, but totally open to restructuring/ideas to make it more readable!
There was a problem hiding this comment.
Gotcha, I think how you have it makes sense! I was moreso curious about cases where we hit the else block but cannot parse the data into an error result. Not sure if that would ever happen though.
… docs for this :(
scannillo
force-pushed
the
networking-refactor-main
branch
from
77cdc78 to
af560e2
Compare
Reason for changes
Restructure vault w/o purchase graphQL call to use new networking layer & add PPaaS API layer.
Summary of changes
HTTPResponseParser<PPaaSAPI>layers toAPIClientto unify process across GraphQL & Rest requestsEncodabletype inRESTRequest&GraphQLRequests instead ofDataVaultPaymentTokensAPIPPaaS layerGraphQLClient_Testsnow thatGraphQLClientis goneHTTPResponseParser_TestsNext
Note
Checklist
Added a changelog entryAuthors
@scannillo