Refactor token used for "temporary" cart when user is unauthenticated

[nicolehaugen]

The current implementation creates a new unique token\id for the cart that is used when the user is unauthenticated. This functionality was implemented prior to real auth existing in the app - we need to now refactor this code for a few different reasons:

1.) There are "TODO" comments that mention this is only temporary until auth is implemented; now that it is, we should remove these

2.) The bigger issue is that the user will end up with an empty cart if they first add items, and then log in - instead, we need to make sure the user doesn't lose their items

[nicolehaugen]

Estimate for this is 2 days

[mjrousos]

Design question - Suppose the user is logged in, adds a few items to their cart, and then logs out. Later, they add items to the cart while not logged in and then log back in. Which of the following is correct:

1. The app should just use the previous cart (and discard the guest one) since they already had a cart.
2. The app should merge their previous cart with the new one.
3. The app should add to the previous cart any items that were in the new guest cart (but not previously in the old cart). It should not add items to the old cart that are already in that cart.

For what it's worth, Amazon seems to take approach 3 (items from my guest card were added to my signed-in cart when I logged in, but I didn't get duplicates).

[chlowell]

In my reading 2 and 3 are the same, and what we want: the set union of the two carts. Each is already a set, so duplicates aren't a concern, and I think SUNION will do the right thing.

[mjrousos]

Ah, I thought that we stored the count of how many a user wanted of a particular sticker somewhere in redis. But it looks like that's not the case, so it should be a simple matter of union'ing the sets. Thanks, @chlowell for pointing that out!