Saved lists and comparison Pro

A wishlist, a monthly reorder list, a specification a builder puts together over a fortnight. Named, kept, and shareable with a colleague.

A list stores what, not how much

A saved item is a product, a variation, and — for a configured product — a reference to the configuration. It is never a stored price.

Every price, stock state and access decision is worked out again at the moment the list is displayed or moved to a basket, by the same engines the shop uses. So a list shows today’s price, today’s stock and today’s trade discount, not whatever was true the day it was saved.

Products that go away, go away

If a product is withdrawn, or moves behind a login, or becomes trade-only, it simply stops appearing on the lists of people who may no longer see it. It is not shown greyed out or marked "unavailable" — that would still tell the viewer something was there, and leave its old name and price on a page belonging to someone who is no longer allowed to see either.

Moving a list into the basket

One button adds everything currently available. Each line goes through exactly the validation a single add-to-cart does: stock, purchasability, your quantity rules, your access policies.

Anything that cannot be added is named, not counted. "Three items could not be added" tells a customer nothing they can act on.

Several lists, and which one the button means

"Save to my list" has to know which list it means, and a signed-in customer may have several. The list page carries the answer: a picker at the top names the list things are being saved to, and switching it changes where the button on every product page files things from then on. The product page itself stays a single button — the confirmation names the list it went to.

That target is remembered, not guessed. Ordering by whichever list was touched most recently would move it every time a customer opened a different one, and they would find things filed somewhere they never chose.

The same picker is where a list is renamed and where another is started. Deleting is offered only when there is a second list to fall back to: the list being saved to cannot be the one that stops existing, and an only list would simply be recreated on the next page view.

Guests keep one list

A signed-in customer can keep several lists. A guest keeps one, and it expires if they never come back — an unbounded amount of state kept for everyone who ever visited is not a feature.

When a guest signs in, the list they built follows them onto their account and stops expiring.

Sharing is private and revocable

Creating a share link issues a random key. The key is stored one-way, so the link works but the database does not hold the link.

Two things follow, and both are the point:

• Creating a new link revokes the old one. The stored value is replaced, so anything already sent stops working.
• Revoking really revokes. There is no key that opens a revoked list.

An unknown list, a revoked link and a wrong key all give the same answer, so the page cannot be used to find out which lists exist. Shared and comparison pages are marked noindex, so a link forwarded to a colleague does not end up in a search engine.

Comparison

Compare two to four products on price, SKU, availability, rating, lead time, weight, dimensions and categories — or whatever subset you choose.

Turn on "differences only" and rows where every product says the same thing are dropped rather than highlighted, so what is left is the actual decision.

The comparison reads the same product objects the shop reads, so a trade customer sees trade prices, a running campaign shows its discount, and a product the shopper cannot see is not in the table at all.