@fanfare-io/fanfare-sdk-react 0.22.0 → 0.23.0

package/README.md

@@ -58,6 +58,14 @@ Customization has four levels of increasing specificity: `theme`, `variant`, `sl
 
 `slots` override targeted states while keeping the default widget flow. `children` receives `{ journey, view, snapshot, error, start, isStarting }` when you want to render the full state yourself.
 
+Mounted inside a shadow root, the widget's styleable elements export CSS parts named after their
+`data-slot`, so a page styles them with `::part()` — `fanfare-host::part(auction-cta)`. The
+attribution footer and every element that contains its "Powered by Fanfare" row are
+deliberately not parts: the widget root and the panel cards that carry that row. The payment
+card field is not a part either. A panel whose footer holds no attribution row keeps its card
+as a part — `auction-module` is one; [`docs/STYLING.md`](./docs/STYLING.md#parts) lists every
+part and every exception.
+
 ## Selection
 
 Some experiences capture which product and variant a consumer gets. `ExperienceWidget` renders that

package/dist/components/checkout/card-brand.d.ts

@@ -0,0 +1,2 @@
+/** The consumer-facing name of a wire card brand (`visa` → `Visa`, `cartes_bancaires` → `Cartes Bancaires`). */
+export declare function cardBrandName(brand: string): string;

package/dist/components/checkout/checkout-processing-panel.d.ts

@@ -5,6 +5,7 @@ import * as React from "react";
  * confirmation.
  *
  * The consumer must not navigate away while the payment settles, so the wait is announced rather
- * than shown only as motion.
+ * than shown only as motion. It reads as the same callout the payment panel shows while a bank
+ * confirmation resumes, so the two waits on one payment look like one wait.
  */
 export declare function CheckoutProcessingPanel(_props: CheckoutProcessingSlotProps): React.ReactElement;

package/dist/components/checkout/payment-collection-panel.d.ts

@@ -5,9 +5,9 @@ import * as React from "react";
  *
  * The hold amount is rendered from the view's own figure — the client never derives one.
  *
- * The configuration block reaches this panel on the entry mount only. A retry is offered from an
- * ended view, which carries none, so that mount renders payment as unavailable and a consumer with
- * a saved method submits without needing Stripe.js at all.
+ * An absent configuration block means its read failed. A saved method pays without Stripe.js, so
+ * with one the outage narrows to the new-card choice; with none, re-reading the configuration is
+ * the panel's only way forward.
  *
  * Entry has no server-side resume: a paused authorization is carried forward by submitting the
  * identical payment input again, held here from the first submit, so exactly one payment method is

package/dist/components/checkout/payment-method-list.d.ts

@@ -0,0 +1,18 @@
+import { PaymentMethodSummary } from '@fanfare-io/fanfare-sdk-core/experiences';
+import type * as React from "react";
+export interface PaymentMethodListProps {
+    methods: PaymentMethodSummary[];
+    /** Unique per panel: radios sharing a name form one group across the whole document. */
+    name: string;
+    selectedId: string | undefined;
+    newCardActive: boolean;
+    /** Offer the new-card row; absent when no card entry can be mounted. */
+    cardEntryAvailable: boolean;
+    onSelectSaved: (id: string) => void;
+    onSelectNew: () => void;
+}
+/**
+ * Saved payment methods and the new-card choice, as one radio group of selector rows. The row look
+ * lives in the theme stylesheet, keyed on `payment-method-row`.
+ */
+export declare function PaymentMethodList({ methods, name, selectedId, newCardActive, cardEntryAvailable, onSelectSaved, onSelectNew, }: PaymentMethodListProps): React.ReactElement;

package/dist/components/checkout/receipt-panel.d.ts

@@ -3,8 +3,9 @@ import * as React from "react";
 /**
  * Default panel for a completed Fanfare-managed payment.
  *
- * The order reference is the outcome. An admission credential appears only on the arm that carries
- * one, and stays subordinate to the purchase: payment is terminal, so a receipt must never read as
- * the thing that admits its holder.
+ * The purchase is the outcome: the panel is labelled as one and leads with what was paid, and the
+ * order reference follows. An admission credential appears only on the arm that carries one, and
+ * stays subordinate to the purchase: payment is terminal, so a receipt must never read as the thing
+ * that admits its holder.
  */
 export declare function ReceiptPanel(props: ReceiptSlotProps): React.ReactElement;

package/dist/components/primitives/spinner.d.ts

@@ -4,6 +4,11 @@ declare const spinnerVariants: (props?: ({
     size?: "sm" | "md" | "lg" | null | undefined;
     styleVariant?: "default" | "rounded" | "retro" | "clean" | null | undefined;
 } & import('class-variance-authority/types').ClassProp) | undefined) => string;
+/**
+ * Whether `Spinner` and `Button` export their CSS `part` names. A subtree a page must never style
+ * from outside — the payment field — renders with it off.
+ */
+export declare const ExportPartsContext: React.Context<boolean>;
 export interface SpinnerProps extends React.SVGAttributes<SVGSVGElement>, Omit<VariantProps<typeof spinnerVariants>, "styleVariant"> {
 }
 export declare const Spinner: React.ForwardRefExoticComponent<SpinnerProps & React.RefAttributes<SVGSVGElement>>;