feat: persist customer product and shop favorites through the live API
Replace mall fixture favorites with customer-scoped endpoints, and send signed-out shoppers back to the page they left after sign-in. Co-authored-by: Cursor <cursoragent@cursor.com>
This commit is contained in:
co-authored by
Cursor
parent
94a64ec712
commit
6c1357ec4d
@@ -0,0 +1,20 @@
|
||||
## ADDED Requirements
|
||||
|
||||
### Requirement: Live customer favorites
|
||||
The mall SHALL use the shared selected API adapter for product and shop favorite state. Product and store detail controls SHALL load persisted state, require customer authentication, prevent duplicate in-flight mutations, and survive reloads. The buyer-center favorites page and dashboard preview/counts SHALL render paginated live favorite results and remove targets through the API instead of reading `MOCK_FAVORITES` or mutating local-only state.
|
||||
|
||||
#### Scenario: product favorite survives reload
|
||||
- **WHEN** a signed-in shopper favorites a product and reloads its detail page
|
||||
- **THEN** the favorite control remains selected from backend state
|
||||
|
||||
#### Scenario: anonymous favorite requires sign-in
|
||||
- **WHEN** a signed-out shopper uses a product or store favorite control
|
||||
- **THEN** the mall sends the shopper to sign in with the current detail URL as the return destination
|
||||
|
||||
#### Scenario: remove from buyer center
|
||||
- **WHEN** a shopper removes a product or shop from the favorites page
|
||||
- **THEN** the API state, visible list, dashboard preview, and visible count reflect the removal without fixture mutation
|
||||
|
||||
#### Scenario: fixed adapter remains functional
|
||||
- **WHEN** the favorites domain is configured to fixed data
|
||||
- **THEN** detail controls and buyer-center favorite flows behave deterministically through the same shared client methods
|
||||
Reference in New Issue
Block a user