metatrondelivery/app/routes/apps.scheduling.availability.tsx
MOHAN 03574a4914 feat: product rules, driving-distance zones, and shipping date ranges
Closes remaining DS-parity gaps from the feature audit:

- ProductRule model (product/collection/vendor/type/tag scoping) with
  real server-side enforcement in hold-request.server.ts, plus shaped
  availability in availability-request.server.ts. Covers per-product
  prep time, cart-content-based slot blocking, and product-restricted
  locations in one mechanism. New /app/rules admin page (Growth+).
- Driving-distance delivery zones via Google's Distance Matrix API,
  cached like existing geocoding results.
- SHIPPING-only estimated arrival range (transitMinDays/transitMaxDays
  on SlotTemplate) — widget shows "Arrives Thu-Sat" instead of a
  meaningless ship-out time slot; carried through to the order
  metafield write-back.

Storefront widget and POS extension now send cart contents (vendor/
type from cart.js, product ids for Admin-API-resolved collection/tag
rules) to both availability and hold endpoints.

checkout-datetime remains excluded from this deploy pending Shopify's
Network Access approval (unrelated to this work) — re-add from
../checkout-datetime-disabled and redeploy once granted.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-08-26 00:28:45 +05:30

55 lines
2.7 KiB
TypeScript

import type { LoaderFunctionArgs } from "@remix-run/node";
import type { Method } from "@prisma/client";
import { authenticate } from "../shopify.server";
import { resolveAvailabilityRequest } from "../services/availability-request.server";
import { resolveProductRefs } from "../services/product-rules.server";
import { parseCartLinesParam, parseProductIdsParam } from "../lib/cart-rule-params";
// Public endpoint, reachable only through Shopify's App Proxy (signature
// verified by authenticate.public.appProxy) — this is what the storefront
// Theme App Extension calls. Requests to https://{shop}/apps/scheduling/*
// forward here because shopify.app.toml's [app_proxy].url already includes
// the /apps/scheduling prefix, so this file's path (apps.scheduling.*)
// mirrors the shop-facing URL exactly. The actual resolution logic lives in
// services/availability-request.server.ts, shared with the POS route
// (pos.scheduling.availability.tsx) — same pool, same code, different auth.
const VALID_METHODS = new Set<Method>(["SHIPPING", "LOCAL_DELIVERY", "PICKUP"]);
export const loader = async ({ request }: LoaderFunctionArgs) => {
const { session, admin } = await authenticate.public.appProxy(request);
if (!session) {
return Response.json({ error: "Shop not found" }, { status: 404 });
}
const url = new URL(request.url);
const methodParam = url.searchParams.get("method");
if (!methodParam || !VALID_METHODS.has(methodParam as Method)) {
return Response.json({ error: "Invalid or missing method" }, { status: 400 });
}
// ProductRule scoping (PRODUCT_STRATEGY.md §2): vendor/type come free from
// the widget's own /cart.js read; product/collection/tag rules additionally
// need one Admin API round trip to resolve productIds — skipped gracefully
// if there's no admin client (shouldn't happen for an installed shop's app
// proxy request, but this endpoint must not 500 over an optional feature).
const productIds = parseProductIdsParam(url.searchParams.get("productIds"));
const productRefs = admin && productIds.length > 0 ? await resolveProductRefs(admin, productIds) : [];
const result = await resolveAvailabilityRequest(session.shop, {
method: methodParam as Method,
locationId: url.searchParams.get("locationId") || undefined,
postalCode: url.searchParams.get("postalCode") || undefined,
address: url.searchParams.get("address") || undefined,
days: Number(url.searchParams.get("days")) || undefined,
cartLines: parseCartLinesParam(url.searchParams.get("cartLines")),
productRefs,
});
if (!result.locationId) {
return Response.json(result, { status: result.error === "No active location configured" ? 404 : 200 });
}
return Response.json(result);
};