@code-collective/booking-widget 1.0.12 → 1.0.13

package/src/lib/TicketConfigurator.svelte

@@ -1,166 +1,166 @@
-<script lang="ts">
-  import type { BookingApi } from './api';
-  import { ApiError, isPriceMismatch } from './api';
-  import type { WizardPages } from './config';
-  import { DEFAULT_WIZARD_PAGES } from './config';
-  import type { CartItem, CheckoutProductDto } from './client-types';
-  import { CartManager } from './cart-manager';
-  import { postMessage } from './messages';
-  import { expandUnitItems } from './utils';
-  import { formatCurrency } from './currency';
-  import WizardPage from './WizardPage.svelte';
-  import { getBookingHostContext, requireBookingService } from './booking-context';
-
-  interface Props {
-    // Optional when a BookingProvider is above this component - it supplies both from its host.
-    api?: BookingApi;
-    cartManager?: CartManager;
-    productId: string;
-    wizardPages?: WizardPages;
-    autoSelectSingleTimeSlot?: boolean;
-    // Whether an add from this configurator asks to be carried on into checkout. Stated on the cart:change
-    // message rather than acted on here, so the host decides how to honour it - and so bw-configurator's
-    // no-auto-checkout attribute and a host's own autoOpenCheckout: false meet in the same branch (see
-    // host.svelte.ts) instead of each build having its own way to suppress it.
-    autoOpenCheckout?: boolean;
-    onCancel?: () => void;
-  }
-  let { api: apiProp, cartManager: cartManagerProp, productId, wizardPages = DEFAULT_WIZARD_PAGES,
-    autoSelectSingleTimeSlot = false, autoOpenCheckout = true, onCancel }: Props = $props();
-
-  const bookingHost = getBookingHostContext();
-  let api = $derived(requireBookingService(apiProp ?? bookingHost?.api, 'TicketConfigurator', 'api'));
-  let cartManager = $derived(
-    requireBookingService(cartManagerProp ?? bookingHost?.cartManager, 'TicketConfigurator', 'cartManager'),
-  );
-
-  let product = $state<CheckoutProductDto | null>(null);
-  let isLoading = $state(true);
-  let isAddingToCart = $state(false);
-  let addToCartError = $state<string | null>(null);
-
-  async function load() {
-    product = await api.getProduct(productId);
-    isLoading = false;
-  }
-
-  load();
-
-  async function addItemToCart(item: CartItem): Promise<void> {
-    await cartManager.ensureCart();
-
-    const unitItems = expandUnitItems(item.units);
-    const added = await api.addCartItem({
-      productId: item.productId,
-      optionId: item.optionId,
-      unitItems,
-      availabilityId: item.availabilityId,
-      localDate: item.localDate,
-      pickupPointId: item.pickupPointId,
-      // Currency and precision are the supplier's to state, not ours - the API resolves both server-side and
-      // ignores anything sent here. Amount stays, but only as a claim about the price the customer was shown:
-      // the server accepts it solely when it matches what the supplier is asking or a price the server itself
-      // published, and returns PRICE_MISMATCH otherwise.
-      amount: item.totalPrice,
-    });
-
-    const total = formatCurrency(item.totalPrice, item.currency, item.currencyPrecision, 2);
-    postMessage({
-      type: 'cart:change',
-      itemCount: unitItems.length,
-      cartItemId: added.id ?? '',
-      totalFormatted: total,
-      openCheckout: autoOpenCheckout,
-    });
-    // Separate from cart:change above - that one is per-item-added detail forwarded to consumers as the
-    // public bw:cart-change event. This one carries the fresh cart itself: CartBar/CartOverviewButton/Checkout
-    // use it to update their own state without each independently re-fetching, and it's forwarded to
-    // consumers as the public bw:cart-updated event/onCartUpdated callback - see this event's own doc comment
-    // in CheckoutModal (the other place it's posted from, after an edit/remove).
-    const cart = await api.getCart().catch(() => null);
-    postMessage({ type: 'cart:updated', cart });
-  }
-
-  async function onAddToCart(item: CartItem) {
-    isAddingToCart = true;
-    addToCartError = null;
-
-    try {
-      await addItemToCart(item);
-    } catch (e) {
-      // The supplier moved the price while the customer was configuring, and the amount they agreed to is no
-      // longer one the server accepts. Retrying is useless - the wizard still holds the old prices, so it
-      // would resubmit exactly the same amount and fail identically. The only way out is to re-fetch and let
-      // the customer see the new price, which is what the message asks them to do.
-      if (isPriceMismatch(e)) {
-        await reloadAfterPriceChange();
-        return;
-      }
-
-      // CartManager only knows a cart is expired from timestamps it saw at creation - it can't see the
-      // server's idle window sliding forward, so a cart that looks valid locally can still be rejected
-      // server-side. A 401/404 here means exactly that: drop the stale cart and retry once with a fresh one
-      // before giving up, rather than leaving the user stuck with no feedback and no way to proceed.
-      const isStaleCart = e instanceof ApiError && (e.status === 401 || e.status === 404);
-      if (isStaleCart) {
-        cartManager.reset();
-        try {
-          await addItemToCart(item);
-        } catch {
-          addToCartError = 'Something went wrong adding this to your cart. Please try again.';
-        }
-      } else {
-        addToCartError = 'Something went wrong adding this to your cart. Please try again.';
-      }
-    } finally {
-      isAddingToCart = false;
-    }
-  }
-
-  async function reloadAfterPriceChange() {
-    addToCartError = "This ticket's price has changed since you started. Please check the updated price and try again.";
-    try {
-      await load();
-    } catch {
-      // The reload is what makes the message actionable; if even that fails the customer needs to start over
-      // rather than be left looking at prices we already know are wrong.
-      addToCartError = "This ticket's price has changed and we could not load the new one. Please reload the page.";
-    }
-  }
-</script>
-
-<div class="bw-widget">
-  {#if isLoading || isAddingToCart}
-    <div class="loading-center" style="height:100vh">
-      <div class="spinner"></div>
-    </div>
-  {:else if product}
-    {#if addToCartError}
-      <p class="add-to-cart-error">{addToCartError}</p>
-    {/if}
-    <WizardPage
-      {product}
-      {api}
-      {wizardPages}
-      {autoSelectSingleTimeSlot}
-      {onCancel}
-      onComplete={onAddToCart}
-    />
-  {/if}
-</div>
-
-<style>
-  /* display: contents - a plain box here would break WizardPage's own .wizard{height:100%}, which needs
-     to resolve against this component's real parent, not an unsized wrapper inserted in between. */
-  .bw-widget {
-    display: contents;
-  }
-
-  .add-to-cart-error {
-    margin: 0;
-    padding: 12px 16px;
-    background: #fdecea;
-    color: #b3261e;
-    font-size: 14px;
-  }
-</style>
+<script lang="ts">
+  import type { BookingApi } from './api';
+  import { ApiError, isPriceMismatch } from './api';
+  import type { WizardPages } from './config';
+  import { DEFAULT_WIZARD_PAGES } from './config';
+  import type { CartItem, CheckoutProductDto } from './client-types';
+  import { CartManager } from './cart-manager';
+  import { postMessage } from './messages';
+  import { expandUnitItems } from './utils';
+  import { formatCurrency } from './currency';
+  import WizardPage from './WizardPage.svelte';
+  import { getBookingHostContext, requireBookingService } from './booking-context';
+
+  interface Props {
+    // Optional when a BookingProvider is above this component - it supplies both from its host.
+    api?: BookingApi;
+    cartManager?: CartManager;
+    productId: string;
+    wizardPages?: WizardPages;
+    autoSelectSingleTimeSlot?: boolean;
+    // Whether an add from this configurator asks to be carried on into checkout. Stated on the cart:change
+    // message rather than acted on here, so the host decides how to honour it - and so bw-configurator's
+    // no-auto-checkout attribute and a host's own autoOpenCheckout: false meet in the same branch (see
+    // host.svelte.ts) instead of each build having its own way to suppress it.
+    autoOpenCheckout?: boolean;
+    onCancel?: () => void;
+  }
+  let { api: apiProp, cartManager: cartManagerProp, productId, wizardPages = DEFAULT_WIZARD_PAGES,
+    autoSelectSingleTimeSlot = false, autoOpenCheckout = true, onCancel }: Props = $props();
+
+  const bookingHost = getBookingHostContext();
+  let api = $derived(requireBookingService(apiProp ?? bookingHost?.api, 'TicketConfigurator', 'api'));
+  let cartManager = $derived(
+    requireBookingService(cartManagerProp ?? bookingHost?.cartManager, 'TicketConfigurator', 'cartManager'),
+  );
+
+  let product = $state<CheckoutProductDto | null>(null);
+  let isLoading = $state(true);
+  let isAddingToCart = $state(false);
+  let addToCartError = $state<string | null>(null);
+
+  async function load() {
+    product = await api.getProduct(productId);
+    isLoading = false;
+  }
+
+  load();
+
+  async function addItemToCart(item: CartItem): Promise<void> {
+    await cartManager.ensureCart();
+
+    const unitItems = expandUnitItems(item.units);
+    const added = await api.addCartItem({
+      productId: item.productId,
+      optionId: item.optionId,
+      unitItems,
+      availabilityId: item.availabilityId,
+      localDate: item.localDate,
+      pickupPointId: item.pickupPointId,
+      // Currency and precision are the supplier's to state, not ours - the API resolves both server-side and
+      // ignores anything sent here. Amount stays, but only as a claim about the price the customer was shown:
+      // the server accepts it solely when it matches what the supplier is asking or a price the server itself
+      // published, and returns PRICE_MISMATCH otherwise.
+      amount: item.totalPrice,
+    });
+
+    const total = formatCurrency(item.totalPrice, item.currency, item.currencyPrecision, 2);
+    postMessage({
+      type: 'cart:change',
+      itemCount: unitItems.length,
+      cartItemId: added.id ?? '',
+      totalFormatted: total,
+      openCheckout: autoOpenCheckout,
+    });
+    // Separate from cart:change above - that one is per-item-added detail forwarded to consumers as the
+    // public bw:cart-change event. This one carries the fresh cart itself: CartBar/CartOverviewButton/Checkout
+    // use it to update their own state without each independently re-fetching, and it's forwarded to
+    // consumers as the public bw:cart-updated event/onCartUpdated callback - see this event's own doc comment
+    // in CheckoutModal (the other place it's posted from, after an edit/remove).
+    const cart = await api.getCart().catch(() => null);
+    postMessage({ type: 'cart:updated', cart });
+  }
+
+  async function onAddToCart(item: CartItem) {
+    isAddingToCart = true;
+    addToCartError = null;
+
+    try {
+      await addItemToCart(item);
+    } catch (e) {
+      // The supplier moved the price while the customer was configuring, and the amount they agreed to is no
+      // longer one the server accepts. Retrying is useless - the wizard still holds the old prices, so it
+      // would resubmit exactly the same amount and fail identically. The only way out is to re-fetch and let
+      // the customer see the new price, which is what the message asks them to do.
+      if (isPriceMismatch(e)) {
+        await reloadAfterPriceChange();
+        return;
+      }
+
+      // CartManager only knows a cart is expired from timestamps it saw at creation - it can't see the
+      // server's idle window sliding forward, so a cart that looks valid locally can still be rejected
+      // server-side. A 401/404 here means exactly that: drop the stale cart and retry once with a fresh one
+      // before giving up, rather than leaving the user stuck with no feedback and no way to proceed.
+      const isStaleCart = e instanceof ApiError && (e.status === 401 || e.status === 404);
+      if (isStaleCart) {
+        cartManager.reset();
+        try {
+          await addItemToCart(item);
+        } catch {
+          addToCartError = 'Something went wrong adding this to your cart. Please try again.';
+        }
+      } else {
+        addToCartError = 'Something went wrong adding this to your cart. Please try again.';
+      }
+    } finally {
+      isAddingToCart = false;
+    }
+  }
+
+  async function reloadAfterPriceChange() {
+    addToCartError = "This ticket's price has changed since you started. Please check the updated price and try again.";
+    try {
+      await load();
+    } catch {
+      // The reload is what makes the message actionable; if even that fails the customer needs to start over
+      // rather than be left looking at prices we already know are wrong.
+      addToCartError = "This ticket's price has changed and we could not load the new one. Please reload the page.";
+    }
+  }
+</script>
+
+<div class="bw-widget">
+  {#if isLoading || isAddingToCart}
+    <div class="loading-center" style="height:100vh">
+      <div class="spinner"></div>
+    </div>
+  {:else if product}
+    {#if addToCartError}
+      <p class="add-to-cart-error">{addToCartError}</p>
+    {/if}
+    <WizardPage
+      {product}
+      {api}
+      {wizardPages}
+      {autoSelectSingleTimeSlot}
+      {onCancel}
+      onComplete={onAddToCart}
+    />
+  {/if}
+</div>
+
+<style>
+  /* display: contents - a plain box here would break WizardPage's own .wizard{height:100%}, which needs
+     to resolve against this component's real parent, not an unsized wrapper inserted in between. */
+  .bw-widget {
+    display: contents;
+  }
+
+  .add-to-cart-error {
+    margin: 0;
+    padding: 12px 16px;
+    background: #fdecea;
+    color: #b3261e;
+    font-size: 14px;
+  }
+</style>

package/src/lib/booking-context.ts

@@ -1,33 +1,33 @@
-// How a BookingProvider hands the host down to the components beneath it, so a consumer writes
-// <TicketConfigurator {productId} /> rather than restating host.api and host.cartManager on every tag. The
-// props are still there and still win - the custom-element wrappers pass them explicitly, because each
-// bw-* element is the root of its own Svelte tree and context does not cross that boundary.
-
-import { getContext, setContext } from 'svelte';
-import type { BookingHost } from './host.svelte';
-
-const BOOKING_HOST = Symbol('booking-host');
-
-/** Call during component initialisation - BookingProvider is the only thing that should need this. */
-export function setBookingHostContext(host: BookingHost): void {
-  setContext(BOOKING_HOST, host);
-}
-
-/** The host from the nearest BookingProvider, or undefined when there is none. */
-export function getBookingHostContext(): BookingHost | undefined {
-  return getContext<BookingHost | undefined>(BOOKING_HOST);
-}
-
-/**
- * Resolves a service a component cannot render without, and says plainly what to do when it is missing.
- * Without this the failure is a `Cannot read properties of undefined` from somewhere deep in a load().
- */
-export function requireBookingService<T>(value: T | undefined, component: string, prop: string): T {
-  if (value === undefined || value === null) {
-    throw new Error(
-      `<${component}> has no ${prop}. Pass ${prop}={...}, or wrap it in ` +
-        `<BookingProvider host={createBookingHost(...)}>.`,
-    );
-  }
-  return value;
-}
+// How a BookingProvider hands the host down to the components beneath it, so a consumer writes
+// <TicketConfigurator {productId} /> rather than restating host.api and host.cartManager on every tag. The
+// props are still there and still win - the custom-element wrappers pass them explicitly, because each
+// bw-* element is the root of its own Svelte tree and context does not cross that boundary.
+
+import { getContext, setContext } from 'svelte';
+import type { BookingHost } from './host.svelte';
+
+const BOOKING_HOST = Symbol('booking-host');
+
+/** Call during component initialisation - BookingProvider is the only thing that should need this. */
+export function setBookingHostContext(host: BookingHost): void {
+  setContext(BOOKING_HOST, host);
+}
+
+/** The host from the nearest BookingProvider, or undefined when there is none. */
+export function getBookingHostContext(): BookingHost | undefined {
+  return getContext<BookingHost | undefined>(BOOKING_HOST);
+}
+
+/**
+ * Resolves a service a component cannot render without, and says plainly what to do when it is missing.
+ * Without this the failure is a `Cannot read properties of undefined` from somewhere deep in a load().
+ */
+export function requireBookingService<T>(value: T | undefined, component: string, prop: string): T {
+  if (value === undefined || value === null) {
+    throw new Error(
+      `<${component}> has no ${prop}. Pass ${prop}={...}, or wrap it in ` +
+        `<BookingProvider host={createBookingHost(...)}>.`,
+    );
+  }
+  return value;
+}

package/src/lib/cart-overview.svelte.ts

@@ -1,97 +1,97 @@
-// The cart state behind both CartOverview presentations. Extracted because the bar and the button had the
-// same load-then-follow-cart:updated logic written twice, and both answered a failed fetch the same wrong
-// way: `cart = null`, rendering exactly what an empty cart renders - nothing at all. On a narrow layout the
-// bar is the only route to checkout, so "no DOM" has to mean something a consumer can act on.
-
-import type { BookingApi } from './api';
-import type { CartManager } from './cart-manager';
-import type { CartOverviewState } from './config';
-import type { CheckoutCartDetailDto } from './client-types';
-import { onWidgetMessage } from './messages';
-
-export interface CartOverview {
-  readonly cart: CheckoutCartDetailDto | null;
-  readonly state: CartOverviewState;
-  /** Re-reads the cart. What the error presentation's retry is wired to. */
-  readonly reload: () => void;
-}
-
-/**
- * Call during component initialisation - it registers an $effect that follows cart:updated for the
- * component's lifetime.
- */
-export function createCartOverview(
-  // Accessors rather than values: these arrive as props, and reading them through a closure keeps this
-  // following the current ones rather than pinning whichever pair happened to be passed on first render.
-  getApi: () => BookingApi,
-  getCartManager: () => CartManager,
-  onStateChange?: (state: CartOverviewState) => void,
-): CartOverview {
-  let cart = $state<CheckoutCartDetailDto | null>(null);
-  let failed = $state(false);
-  let isLoading = $state(true);
-  // Only the newest load may write. A read still in flight when a fresher cart arrives - from a retry, or
-  // from cart:updated after an add elsewhere on the page - would otherwise land afterwards and overwrite it,
-  // and a transient failure landing late would replace a perfectly good cart summary with the error view.
-  let currentLoad = 0;
-
-  async function load() {
-    const thisLoad = ++currentLoad;
-    isLoading = true;
-    failed = false;
-    // No token held means there is genuinely nothing to fetch - an empty cart, not a failure.
-    if (!getCartManager().hasCart) {
-      cart = null;
-      isLoading = false;
-      return;
-    }
-    try {
-      const loaded = await getApi().getCart();
-      if (thisLoad !== currentLoad) return;
-      cart = loaded;
-    } catch {
-      if (thisLoad !== currentLoad) return;
-      cart = null;
-      failed = true;
-    }
-    isLoading = false;
-  }
-
-  void load();
-
-  // load() only runs once - without this, adding/editing/removing an item elsewhere on the page (the
-  // configurator, or the checkout modal's own edit/remove) leaves this showing a stale total. The event
-  // already carries the fresh cart (see TicketConfigurator/CheckoutModal's own posting sites), so it is
-  // applied directly rather than triggering a second, redundant getCart() call.
-  $effect(() =>
-    onWidgetMessage((d) => {
-      if (d.type === 'cart:updated') {
-        // Supersedes any read still in flight - this cart is newer than whatever it will return.
-        currentLoad += 1;
-        cart = d.cart;
-        // A cart arriving by message is a cart successfully read somewhere else on the page, so whatever
-        // this one's own fetch ran into is no longer the current answer.
-        failed = false;
-        isLoading = false;
-      }
-    }),
-  );
-
-  const state = $derived<CartOverviewState>(
-    isLoading ? 'loading' : failed ? 'error' : (cart?.items?.length ?? 0) > 0 ? 'ready' : 'empty',
-  );
-
-  $effect(() => {
-    onStateChange?.(state);
-  });
-
-  return {
-    get cart() {
-      return cart;
-    },
-    get state() {
-      return state;
-    },
-    reload: () => void load(),
-  };
-}
+// The cart state behind both CartOverview presentations. Extracted because the bar and the button had the
+// same load-then-follow-cart:updated logic written twice, and both answered a failed fetch the same wrong
+// way: `cart = null`, rendering exactly what an empty cart renders - nothing at all. On a narrow layout the
+// bar is the only route to checkout, so "no DOM" has to mean something a consumer can act on.
+
+import type { BookingApi } from './api';
+import type { CartManager } from './cart-manager';
+import type { CartOverviewState } from './config';
+import type { CheckoutCartDetailDto } from './client-types';
+import { onWidgetMessage } from './messages';
+
+export interface CartOverview {
+  readonly cart: CheckoutCartDetailDto | null;
+  readonly state: CartOverviewState;
+  /** Re-reads the cart. What the error presentation's retry is wired to. */
+  readonly reload: () => void;
+}
+
+/**
+ * Call during component initialisation - it registers an $effect that follows cart:updated for the
+ * component's lifetime.
+ */
+export function createCartOverview(
+  // Accessors rather than values: these arrive as props, and reading them through a closure keeps this
+  // following the current ones rather than pinning whichever pair happened to be passed on first render.
+  getApi: () => BookingApi,
+  getCartManager: () => CartManager,
+  onStateChange?: (state: CartOverviewState) => void,
+): CartOverview {
+  let cart = $state<CheckoutCartDetailDto | null>(null);
+  let failed = $state(false);
+  let isLoading = $state(true);
+  // Only the newest load may write. A read still in flight when a fresher cart arrives - from a retry, or
+  // from cart:updated after an add elsewhere on the page - would otherwise land afterwards and overwrite it,
+  // and a transient failure landing late would replace a perfectly good cart summary with the error view.
+  let currentLoad = 0;
+
+  async function load() {
+    const thisLoad = ++currentLoad;
+    isLoading = true;
+    failed = false;
+    // No token held means there is genuinely nothing to fetch - an empty cart, not a failure.
+    if (!getCartManager().hasCart) {
+      cart = null;
+      isLoading = false;
+      return;
+    }
+    try {
+      const loaded = await getApi().getCart();
+      if (thisLoad !== currentLoad) return;
+      cart = loaded;
+    } catch {
+      if (thisLoad !== currentLoad) return;
+      cart = null;
+      failed = true;
+    }
+    isLoading = false;
+  }
+
+  void load();
+
+  // load() only runs once - without this, adding/editing/removing an item elsewhere on the page (the
+  // configurator, or the checkout modal's own edit/remove) leaves this showing a stale total. The event
+  // already carries the fresh cart (see TicketConfigurator/CheckoutModal's own posting sites), so it is
+  // applied directly rather than triggering a second, redundant getCart() call.
+  $effect(() =>
+    onWidgetMessage((d) => {
+      if (d.type === 'cart:updated') {
+        // Supersedes any read still in flight - this cart is newer than whatever it will return.
+        currentLoad += 1;
+        cart = d.cart;
+        // A cart arriving by message is a cart successfully read somewhere else on the page, so whatever
+        // this one's own fetch ran into is no longer the current answer.
+        failed = false;
+        isLoading = false;
+      }
+    }),
+  );
+
+  const state = $derived<CartOverviewState>(
+    isLoading ? 'loading' : failed ? 'error' : (cart?.items?.length ?? 0) > 0 ? 'ready' : 'empty',
+  );
+
+  $effect(() => {
+    onStateChange?.(state);
+  });
+
+  return {
+    get cart() {
+      return cart;
+    },
+    get state() {
+      return state;
+    },
+    reload: () => void load(),
+  };
+}

package/src/lib/client-types.ts

@@ -23,17 +23,21 @@ export type CheckoutCartConfirmItemResultDto = S['CheckoutCartConfirmItemResultD
 export type OctoContact = S['OctoContact'];
 
 // Client-side types
-export type PaymentOutcome = 'successful' | 'pending' | 'failed' | 'cancelled';
+// 'partial' is its own outcome rather than a kind of 'failed' because the shopper's card WAS charged: the
+// payment succeeded and only some of the booking's items could be confirmed afterwards. It gets a heading of
+// its own in ResultView, since "Payment Failed" printed over the words "Your payment succeeded" invites
+// exactly the wrong reaction - paying again elsewhere, or charging back a payment that did go through.
+export type PaymentOutcome = 'successful' | 'pending' | 'partial' | 'failed' | 'cancelled';
 
 export interface PaymentStatus {
   outcome: PaymentOutcome;
   resultCode?: string;
   resultDescription?: string;
-  // Only meaningful for outcome 'failed'. A card that was actually charged - which is every 'failed' this
-  // gateway produces once confirmation itself is what failed, not the payment - must never be offered a
-  // "try again" that re-opens the card form, since the shopper would be charged a second time for a booking
-  // that already has their money against it. Defaults true (the ordinary declined/expired/errored case,
-  // where nothing was charged and retrying is exactly correct) so existing callers need not set it.
+  // Only meaningful for outcome 'failed', and only for a 'failed' that nonetheless took the shopper's money:
+  // it must never be offered a "try again" that re-opens the card form, since they would be charged a second
+  // time for a booking that already has their money against it. Defaults true (the ordinary declined/expired/
+  // errored case, where nothing was charged and retrying is exactly correct) so existing callers need not set
+  // it. The confirm-partial case this was first introduced for now carries its own 'partial' outcome.
   retryPayment?: boolean;
 }