Feature/favorites filter issue #35 #55

2026-08-18T15:17:28-05:00

bermudalamb commented

2026-08-18 15:17:28 -05:00

No description provided.

bermudalamb added 2 commits 2026-08-18 15:17:28 -05:00

feat: filter the storefront by favorited items (#35 ) d4e2abe743

Adds favorites as another dimension of the existing storefront filter rather than a separate view, so it lives in the URL, shows up as a removable chip, and combines with category, tags, and price by AND like everything else. A customer can ask for "my favorites under $500 in Furniture" instead of only "my favorites".

Sold favorites are included. The storefront shows sold items everywhere else, and a favorite that has just sold is often exactly what the customer came back to look at after being emailed about it in #34. Hiding them would make items disappear from a list the customer curated themselves. Anyone wanting only what they can still buy can combine the toggle with the status filter.

Which customer "my favorites" means comes from the session, never from the query string, so a hand-edited URL cannot name someone else's favorites. A signed-out visitor sees the toggle and gets the same inline register/login prompt the heart button and Add to Cart already use; signing in resolves the gate and the filter applies on its own. A bookmarked favorites link whose session has expired says so rather than rendering an empty grid, which would tell the visitor they have no favorites instead of that we do not know who they are. The API answers 401 for the same reason, and the admin inventory refuses the filter outright rather than ignoring it.

The shared SQL builder now requires callers to say whose favorites they mean, even when that is nobody, and throws instead of dropping the clause — a future caller that forgets the guard fails loudly rather than quietly returning the whole catalogue.

Verified with 59 unit tests, 134 backend integration tests, and 70 end-to-end tests, all passing, with type checking clean on both sides.

docs: record the favorites filter and the Node version trap

SonarQube Analysis / sonarqube (pull_request) Successful in 3m8s

Details

Tests / backend-unit (pull_request) Successful in 41s

Details

Tests / frontend-e2e (pull_request) Failing after 8m36s

Details

1249f9a311

Notes that the default local Node (18.16.1) cannot run either the integration suite or Playwright, and that neither failure names the version as the cause — the integration one reads like a broken lru-cache dependency. Records the newer version's path so a single command can be run against it without switching what the user has active.

Adds two e2e lessons from this change: isVisible() does not wait, so guarding an optional dialog with it loses the race and leaves an antd modal open to intercept every later click; and under fullyParallel a test that mutates a shared fixture races its siblings.

Records that the storefront listing sold items is now load-bearing rather than merely tolerated, since the favorites filter deliberately shows sold favorites, and points at the favorites filter as the pattern for any future filter dimension that depends on who is asking.

bermudalamb merged commit 0f04cd25cd into main

2026-08-18 15:17:34 -05:00

bermudalamb deleted branch feature/favorites-filter

2026-08-18 15:17:35 -05:00

bermudalamb added this to the Initial Build project 2026-08-18 15:24:59 -05:00

bermudalamb moved this to Ready for Release in Initial Build on 2026-08-18 15:25:06 -05:00

bermudalamb self-assigned this 2026-08-18 15:26:25 -05:00

bermudalamb requested review from calamb 2026-08-18 15:26:29 -05:00

bermudalamb changed title from ~~Feature/favorites filter~~ to Feature/favorites filter issue #35

2026-08-18 15:28:14 -05:00

bermudalamb moved this to Released in Initial Build on 2026-08-19 10:42:07 -05:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: bermudalamb/redefined-designs#55