SAP / SAP/spartacus-docs

Discussion/doc cart's behaviour

Open
#203 2 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
HTML
Stars
11
Forks
22
Avg merge
7d 3h
Merged PRs (30d)
2

Description

There are many nuances in the cart's mechanism. It would be good to document all those. Then we can think of optimizing current architecture of OCC API and Sparatacus code. We should also cover all those documented nuances with e2e tests.

For example:

  • cart of anonymous user is merged into exiting user's cart after login
  • for calls to OCC we use userId 'anonymous' for unsigned users and real userId for signed ones
  • for calls to OCC we use cartId 'current' (or cart.code? I'm not sure) for signed users and cart.guid for unsigned users
  • we shouldn't load cart from backend when it's not created (question: it may be OK for unsigned users, but for signed may lead to two active carts on different devices, see https://github.com/SAP/cloud-commerce-spartacus-storefront/issues/3592)
  • we should re-load cart from backend after all actions, i.e. like add cart entry (question: can we optimize backend API to return cart as a result of adding cart entry?)
  • when cart doesn't exist in backend, we should create it just before user adds the first item to the cart
  • question: can/should a signed user have different carts on different devices? (I guess not)

It's an open discussion. So please share thoughts in comments.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

No file or test path is named. Review the existing cart documentation, OCC API behavior, Spartacus cart code, and issue 3592, then resolve the open questions before documenting the agreed scenarios and adding e2e coverage.

Written by the indexing model from the issue text.

Assessment

Domain
backend-api-design, documentation, testing
Issue type
Documentation
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.