Shopping by events

Events are things that have happened, so should be in the past tense.

• ListCreated

  • listId
  • listName
  • ownerId (maybe)

• ListDeleted

  • listId

• ItemCreated

  • listId
  • itemId
  • itemName
  • itemState

• ItemUpdated

  • listId
  • itemId
  • itemName
  • itemState

• ItemDeleted

  • listId
  • itemId

I might have been over thinking sharing. If I add an Out Of Band (OOB) portion, then it all becomes much easier.

• User A clicks "Share List"
• Server generates a unique id and stores it along with the list id, user id, and timestamp
• Server gives User A a link containing the id
• User A sends the link to user B OOB
• User B uses the link
• Sever uses the id to look up the list and:
  • Adds User B to the users for the list
  • Deletes the id
  • Notifies User A

Need to add user models, including a per-user notification queue.

Also need new events for ListShared (or UserAdded, can't decide which).

Also need to think about commands, since the local client can't create share links. (But most traffic from local client will still be events, as the thing will have happened by the time the server funds out about it)

Rule: The local client is the source of truth.

is there any need for lists to have a clock? Yes, need to be able to order events well enough that lists are consistent between users.

I've been thinking about writing a build-time tool to replace strings in source files (specifically to add version numbers to <script> tags, and to the load service worker call), and I've just realised that if/since I'm doing build time shenanigans anyway, I might as well do JS/CSS/HTML minification at the same time.

(I was going to say something about HTML minification being hard as it interacts with the ASP stuff, but that's what Rosyln is for, yeah?)