feat(store-api): Add cart to store-api #963
Conversation
|
✔️ Deploy Preview for storeui ready! 🔨 Explore the source changes: 7511598 🔍 Inspect the deploy log: https://app.netlify.com/sites/storeui/deploys/61577e8adc28e500077b995e 😎 Browse the preview: https://deploy-preview-963--storeui.netlify.app |
|
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. Latest deployment of this branch, based on commit 7511598:
|
tlgimenes
force-pushed
the
feat/api-cart
branch
from
2d0a99b to
05ee757
Compare
packages/store-api/src/platforms/vtex/clients/commerce/types/OrderForm.ts
Outdated
Show resolved
Hide resolved
packages/store-api/src/platforms/vtex/resolvers/validateCart.ts
Outdated
Show resolved
Hide resolved
packages/store-api/src/platforms/vtex/resolvers/validateCart.ts
Outdated
Show resolved
Hide resolved
packages/store-api/src/platforms/vtex/resolvers/validateCart.ts
Outdated
Show resolved
Hide resolved
packages/store-api/src/platforms/vtex/resolvers/validateCart.ts
Outdated
Show resolved
Hide resolved
| listPrice: item.listPrice / 100, | ||
| price: item.sellingPrice / 100, |
There was a problem hiding this comment.
I prefer to transfer this data over the net with a natural value, not a float.
There was a problem hiding this comment.
Why so? doing this will make us do this computation on the frontend
packages/store-api/src/platforms/vtex/clients/commerce/index.ts
Outdated
Show resolved
Hide resolved
packages/store-api/src/platforms/vtex/clients/commerce/types/OrderForm.ts
Outdated
Show resolved
Hide resolved
packages/store-api/src/platforms/vtex/clients/commerce/types/OrderForm.ts
Show resolved
Hide resolved
| /** | ||
| * This resolver implements the optimistic cart behavior. The main idea in here | ||
| * is that we receive a cart from the UI (as query params) and we validate it with | ||
| * the commerce platform. If the cart is valid, we return null, if the cart is |
There was a problem hiding this comment.
Not so sure about returning null to signify that "no changes were made", or "the cart is valid".
Why not add a field to the returned orderForm like updated, which would be a boolean value? Then we always return back the orderForm, but with an easy way for the frontend to check if the cart should be updated or not
There was a problem hiding this comment.
Just to save data. These carts can be big and it would be nice to save a little bit of bandwidth when the cart is valid
There was a problem hiding this comment.
What do you think?
There was a problem hiding this comment.
Yeah, makes sense!
I don't know how users will react to this hahahaha they might not find it weird. But regardless, from a performance standpoint, I agree. This is a great way to save data when dealing with big carts 😄 Especially taking into account poor mobile connections.
packages/store-api/src/platforms/vtex/clients/commerce/index.ts
Outdated
Show resolved
Hide resolved
packages/store-api/src/platforms/vtex/clients/commerce/index.ts
Outdated
Show resolved
Hide resolved
packages/store-api/src/platforms/vtex/resolvers/validateCart.ts
Outdated
Show resolved
Hide resolved
tlgimenes
force-pushed
the
feat/api-cart
branch
from
a09335c to
8e69713
Compare
packages/store-api/src/platforms/vtex/clients/commerce/index.ts
Outdated
Show resolved
Hide resolved
tlgimenes
force-pushed
the
feat/api-cart
branch
from
13006bb to
002d984
Compare
What's the purpose of this pull request?
This PR adds an optimistic cart implementation to store-api.
How it works?
The optimistic cart we have works via state validation. This means that, we build a state of the cart on the browser, and then, the backend validates this state. If this state is valid, the backend signalizes this state is ok and nothing changes on the frontend. If, however, this state is not valid, a.k.a, this product is unavailable, a promotion was applied, etc, the backend sends the new cart state to the frontend. An example of this process can be seen below:
To implement the cart, I used the schema.org's type
Order. Also, another thing this PR brings isinputfields. We didn't really use them before, but now I needed a standard for writing them. I added anIprefix to them, so writing aninputfor atypecan be achieved by:type StoreProduct->type IStoreProduct.Also, another thing this PR brings is the usage of dataloaders. This was necessary for loading skus and simulations without overwhelming the search/checkout API.
How to test it?
To test it, open our PR on base.store and check that all promotions are applied correctly. Also, if you want you can change the base account name to
carrefourbrfoodand check all edge cases in there.vtex-sites/base.store#36