metatroncubeswdev 5b2207a397
Some checks failed
CI / Lint, Unit & Integration Tests (push) Has been cancelled
feat: Phase 7 — POS + Checkout UI extensions
Also fixes the [events] gate that was blocking ALL extension generation
(discovered while starting this phase).

- shopify.app.toml: this org appears enrolled in Shopify's "Next
  Generation Events" developer preview, which the CLI now treats as a
  REQUIRED top-level [events] section even though nothing in this app
  actually uses it (real webhook handling is entirely classic [webhooks],
  unaffected). Iteratively discovered the required shape from the CLI's
  own field-by-field validation errors, then found the real docs (Events
  is optional/developer-preview, api_version pinned to "unstable") to
  confirm rather than keep guessing. Added a functionally-inert
  [[events.subscription]] placeholder + a stub handler
  (webhooks.events.placeholder.tsx) solely to satisfy the gate.

- app/services/availability-request.server.ts +
  app/services/hold-request.server.ts: extracted the resolution logic that
  used to live directly in apps.scheduling.availability.tsx/hold.tsx into
  shared functions. This is what actually makes "same capacity pool feeds
  every surface" (CLAUDE.md) true by construction rather than by
  convention — the storefront, POS, and checkout routes now call the exact
  same code, not three copies that could quietly drift apart.

- extensions/pos-datetime (generated via `shopify app generate extension
  --template=pos_smart_grid` — pos_action's flavor requirement contradicted
  the CLI's own global --flavor validator, so smart_grid was used instead):
  a home-screen tile opening a modal where staff pick method -> date -> time
  against the same availability/hold endpoints (pos.scheduling.*.tsx,
  session-token authenticated), writing the same dd_* cart properties via
  CartApi.addCartProperties — booking.server.ts needed zero changes to
  handle POS-originated orders. Several API-shape guesses (toast isError
  option, ChoiceList's `value`/`label` props, a nonexistent
  action.dismissModal(), shopify.cart.cart.current) were wrong and caught
  by typechecking directly against @shopify/ui-extensions' own bundled
  .d.ts files (`npm run typecheck:pos`, now also in CI) — none of this was
  verified against a live POS session, which isn't possible in this
  environment.

- extensions/checkout-datetime (generated via `--template=checkout_ui`):
  the Plus-only native picker in checkout itself
  (purchase.checkout.block.render) plus a Thank You confirmation block
  (purchase.thank-you.block.render). Went looking for an order-status
  target too ("all plans show confirmed slot on thank-you/order-status" is
  the Phase 7 accept criterion) and confirmed via the installed package's
  own type definitions that purchase.order-status.block.render does not
  exist in this API version — checkout UI extensions' thank-you/order-status
  surfaces are Plus-only regardless. The actual "all plans" mechanism is
  extensions/datetime-widget/blocks/order-confirmation.liquid — a new Theme
  App Extension block reading order.note_attributes, which works on every
  plan since it's plain Liquid, not checkout extensibility.

Both new UI extensions share one real unverified assumption, called out in
code comments: process.env.APP_URL is expected to be substituted at build
time by the Shopify CLI to the app's backend origin, since these run in a
different origin than the app and need an absolute URL, unlike the
storefront widget's relative /apps/scheduling/* path. Needs confirming
against a live dev session.

Verified: lint, typecheck (root + both new extensions'
`npm run typecheck:pos`/`typecheck:checkout`, all now in CI), 102 unit +
18 integration tests (unchanged — this phase didn't touch pure business
logic, only added thin auth wrappers around already-tested services), both
admin/widget builds.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-08-24 09:11:34 -04:00

43 lines
1.7 KiB
Plaintext

{%- comment -%}
Works on every plan (Order Status / Thank You are plain Liquid-rendered
pages outside checkout extensibility for non-Plus stores) — reads the
same dd_* attributes the storefront widget/POS/Plus checkout all write,
which Shopify carries from cart attributes onto order.note_attributes
automatically. This is the actual "all plans show confirmed slot on
thank-you/order-status" piece (IMPLEMENTATION_PLAN.md Phase 7); the
Checkout UI Extension's Thank You block (extensions/checkout-datetime) is
an additional, Plus-only nicety layered on top, not a substitute for this.
{%- endcomment -%}
{%- assign dd_method = blank -%}
{%- assign dd_display = blank -%}
{%- for attribute in order.note_attributes -%}
{%- if attribute.name == "dd_method" -%}
{%- assign dd_method = attribute.value -%}
{%- endif -%}
{%- if attribute.name == "Pickup date" or attribute.name == "Delivery date" or attribute.name == "Shipping date" -%}
{%- assign dd_display = attribute.value -%}
{%- endif -%}
{%- endfor -%}
{%- if dd_method != blank and dd_display != blank -%}
<div class="dd-order-confirmation" {{ block.shopify_attributes }}>
<p class="dd-order-confirmation__label">
{%- case dd_method -%}
{%- when "PICKUP" -%}{{ 'order_confirmation.pickup_label' | t }}
{%- when "LOCAL_DELIVERY" -%}{{ 'order_confirmation.delivery_label' | t }}
{%- else -%}{{ 'order_confirmation.shipping_label' | t }}
{%- endcase -%}
</p>
<p class="dd-order-confirmation__value">{{ dd_display }}</p>
</div>
{%- endif -%}
{% schema %}
{
"name": "t:order_confirmation.name",
"target": "section",
"settings": []
}
{% endschema %}