feat: Consider order number from Checkout cookie #2592
Merged
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
lucasfp13
added
the
don't merge
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
|
This pull request is automatically built and testable in CodeSandbox. To see build info of the built libraries, click here or the icon next to each commit SHA. |
lucasfp13
changed the title
orderFormId from Checkout cookie
lucasfp13
changed the title
orderFormId from Checkout cookie
lucasfp13
removed
the
don't merge
lucasfp13
requested review from
lariciamota and
pedromtec
and removed request for
a team
lucasfp13
force-pushed
the
test/ofid-from-cookie
branch
from
ba6ccba to
5c99afb
Compare
lariciamota
approved these changes
Jan 9, 2025
There was a problem hiding this comment.
LGTM!
Tested the checkout placing an order using https://teste.paladino.co/ and also tested the minicart and the navigation to checkout page using the preview https://sfj-1573732--starter.preview.vtex.app/
pedromtec
approved these changes
Jan 9, 2025
emersonlaurentino
force-pushed
the
test/ofid-from-cookie
branch
from
5c99afb to
2d0af99
Compare
eduardoformiga
pushed a commit
that referenced
this pull request
Jan 15, 2025
## What's the purpose of this pull request? This PR intends to change how we set the order number value on `@faststore/api`. ## How it works? Currently, we set the `orderNumber` value as the one we receive from client-side's storage context. After the order placed, Checkout generates a new order number (a new cart) and send it through the `checkout.vtex.com` cookie, but we do not update this value in the client-side's storage context until the `validateCart` resolver is executed (in the next `ValidateCartMutation` request). At the resolver, we always consider the order number's default value as being the one from client-side's storage context, not the updated one incoming from Checkout cookie. So with this change we will consider the order number value from the `checkout.vtex.com` cookie as the default one, and change the other to be the fallback case. ## How to test it? The following store was created to validate the scenario with both storefront and checkout integrated on the same domain: https://teste.paladino.co/ Perform the entire checkout flow. The payment type should be with "money". After the order placed, check the `orderFormId` in `checkout.vtex.com` cookie, it should be a new one. When returning to the store also check the `orderFormId` from storage context, it should be the same as the cookie one. The cart should be empty too. We need to check if, aside from the order placed flow, everything is working properly on a current store (use the `starter.store` preview, with the secure subdomain), add/remove items in the cart, clear the cart, go to checkout etc. ### Starters Deploy Preview vtex-sites/starter.store#647 --------- Co-authored-by: Emerson Laurentino <[email protected]>
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.
What's the purpose of this pull request?
This PR intends to change how we set the order number value on
@faststore/api.How it works?
Currently, we set the
orderNumbervalue as the one we receive from client-side's storage context. After the order placed, Checkout generates a new order number (a new cart) and send it through thecheckout.vtex.comcookie, but we do not update this value in the client-side's storage context until thevalidateCartresolver is executed (in the nextValidateCartMutationrequest). At the resolver, we always consider the order number's default value as being the one from client-side's storage context, not the updated one incoming from Checkout cookie.So with this change we will consider the order number value from the
checkout.vtex.comcookie as the default one, and change the other to be the fallback case.How to test it?
The following store was created to validate the scenario with both storefront and checkout integrated on the same domain: https://teste.paladino.co/
Perform the entire checkout flow. The payment type should be with "money". After the order placed, check the
orderFormIdincheckout.vtex.comcookie, it should be a new one. When returning to the store also check theorderFormIdfrom storage context, it should be the same as the cookie one. The cart should be empty too.We need to check if, aside from the order placed flow, everything is working properly on a current store (use the
starter.storepreview, with the secure subdomain), add/remove items in the cart, clear the cart, go to checkout etc.Starters Deploy Preview
vtex-sites/starter.store#647