rockerest’s avatarrockerest’s Twitter Archive—№ 19,225

          1. …in reply to @kmelve
            kmelve I think it depends on how dynamic it needs to be. I'd start from the principal that I want as much done statically as possible: so all those product pages are generated on a publish (presumably this is a button click in a CMS somewhere).
        1. …in reply to @rockerest
          kmelve I'd scatter in web components where necessary: probably the buy/price box, and the shopping cart widget, plus the checkout process (although I'd try to punt that out to a third party rather than roll my own).
      1. …in reply to @rockerest
        kmelve For the interaction between purchasing and the cart, I'd use an event mediator / message bus pattern, and a finite state machine for the individual parts (e.g. a spinner when you click add to cart, or whatever similar states you have).
    1. …in reply to @rockerest
      kmelve I'm always looking for a reason to use IndexedDB, but for JUST what I've described above it's probably super overkill, so I'd probably keep tabs of what the user thinks they have in their cart - obviously synced to the API for carts (also third party??) as frequently as possible.
  1. …in reply to @rockerest
    kmelve Most likely keeping tabs this way could be a simple localStorage key, but the appropriateness of that will vary depending on a lot. I'd almost try to avoid any local storage and rely on the shopping cart API to keep that synced. It's the final authority anyway.
    1. …in reply to @rockerest
      kmelve There's obviously a ton of nuance here, but there it is: - Static as much as possible up front - Event mediator for app-level communication - WC for highly dynamic things (price/buy box, cart) - Third party for checkout/cart API