update validateCart logic

[beatrizmaselli]

What's the purpose of this pull request?

The validateCart creates the orderForm without the customData the first time it happens at the site because the orderNumber still do not exist at the cookies or at the cartStorage.

With this change when the orderForm is being created by FastStore we will set the new orderForm already with the customData.

The problem is that when the client just entered the site the first validateCart Mutation will only set the cookie but if the second validate Cart Mutation already is an add to Cart the orderForm will have isStale true because the customData was not set at the first request and the items wont be added. The second request would work but it causes an experience problem for the client.

How to test it?

Run the code locally and try the request of the validateCart to create the orderForm:

curl --location 'http://localhost:3000/api/graphql?operationName=ValidateCartMutation&operationHash=87e1ba227013cb087bcbb35584c1b0b7cdf612ef' \
--header 'Accept: */*' \
--header 'Cache-Control: no-cache' \
--header 'Connection: keep-alive' \
--header 'Content-Type: application/json' \
--header 'Cookie;' \
--header 'Origin: http://localhost:3000' \
--header 'Referer: http://localhost:3000/' \
--data '{
    "operationName": "ValidateCartMutation",
    "operationHash": "87e1ba227013cb087bcbb35584c1b0b7cdf612ef",
    "variables": {
        "session": {
            "currency": {
                "code": "USD",
                "symbol": "$"
            },
            "locale": "en-US",
            "channel": "{\"salesChannel\":\"1\",\"regionId\":\"\"}",
            "country": "USA",
            "deliveryMode": null,
            "addressType": null,
            "postalCode": null,
            "geoCoordinates": null,
            "person": null
        },
        "cart": {
            "order": {
                "orderNumber": "",
                "shouldSplitItem": true,
                "acceptedOffer": []
            }
        }
    }
}'

Validate that the orderForm is created with the customData:

curl --location 'https://storeframework.vtexcommercestable.com.br/api/checkout/pub/orderForm/{{orderFormId}}' \
--header 'Accept: application/json' \
--header 'Content-Type: application/json'

Do the same using the code before and check that the first ValidateCart Mutation will set the cookie but if you do the get the customData is not set yet. Only the second request will in fact set the customData.

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
faststore-site	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Mar 25, 2024 2:46pm

[codesandbox-ci]

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.

[icazevedo]

I think this works, but this disables a behavior while creating another. Previously, if you didn't have an order number, you'd be able to get one & set items to it all in one mutation. This PR disables this behavior.

This won't be a problem in real day-to-day use because this PR makes it so that we'll start getting the orderNumber as soon as the user enters the page, which leads to it always being there when users try to add items to the cart.

But I think it's relevant to bring that to the table and consider if that's what we want and if it won't break any other behaviors. For example, now, the orderNumber will hardly be undefined as it often was, which may lead to the cookie not being considered as it was previously.

[beatrizmaselli]

I think this works, but this disables a behavior while creating another. Previously, if you didn't have an order number, you'd be able to get one & set items to it all in one mutation. This PR disables this behavior.

This won't be a problem in real day-to-day use because this PR makes it so that we'll start getting the orderNumber as soon as the user enters the page, which leads to it always being there when users try to add items to the cart.

But I think it's relevant to bring that to the table and consider if that's what we want and if it won't break any other behaviors. For example, now, the orderNumber will hardly be undefined as it often was, which may lead to the cookie not being considered as it was previously.

This change of behaviour will be analysed in a separate PR and we are keeping the same one for now.