Checkout API to Cart API migration #1000
Draft
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Co-authored-by: Juan P. Prieto <[email protected]>
Before these tests weren't actually testing anything useful - the API response was mocked, and then the test ensured that the mock returned the return value we mocked. Now these tests execute actual storefront API calls, and are now useful integration tests that we can trust.
The goal of this commit is to isolate the non-test, non-doc code changes to be reviewed. This commit contains: - Changes to the GQL operations used in the checkout resource - Input and payload mapping to match the previous inputs/payloads as closely as possible This commit does NOT contain: - Unit tests - Integration tests - Migration guide - Docs updates Co-authored-by: Juan P. Prieto <[email protected]>
In cart-payload-mapper-test, these are just unit tests. All of the other tests make actual SF API calls and verify that the response returned from the SDK is what we expect. Our goal here is to ensure that when a given checkout method is called with SDK v3, the response is the same as what previous versions of the SDK returned (aside from known/documented discrepancies between the cart/checkout APIs). In the tests, the "expected" values are all values that we got when we ran these operations with the previous SDK version. The "actual" values are what v3 of the SDK returns for the same operation. Co-authored-by: Juan P. Prieto <[email protected]>
Co-authored-by: Juan P. Prieto <[email protected]>
Fix table formatting
This property is added on by the GraphQL JS client. `hasPreviousPage` was coming out as true and `hasNextPage` was coming out as false, but since we fetch all pages and give them back as a single array, those values are misleading, so now we're hard-coding them both to false.
As a sanity check during the development phase, we were throwing an error if we were aware of a discount code but it wasn't appearing in the output of our discount mapping. Upon investigating further, we determined that this is expected behaviour for any discount codes that are applied but have `applicable: false`. Therefore, we are updating our sanity check to only throw an error if the discount code IS applied but somehow didn't get mapped. These sanity checks that throw errors will be removed before release.
The assertions were slightly off, since the item is $70 rather than $73.5.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Public SDK deprecation notice
WHY are these changes introduced?
The main goal of this (final) version of the SDK is to extend the longevity of its
.checkoutinterface by replacing it with an equivalent interface based on the Cart APIWHAT is this pull request doing?
Replaces the
Checkout APIdependency from all.checkoutinterface methods such asfetch,addLines,removeLinesetc. All existing checkout methods now use Cart API equivalents under the hood.HOW to test your changes?
Checklist