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>
55 lines
2.7 KiB
TypeScript
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);
|
|
};
|