@nexus-cross/dapp-ui 1.3.10-beta.4 → 1.3.10-beta.6

package/dist/index.d.cts

@@ -1890,10 +1890,10 @@ interface DepositAddressResult {
     originCurrency: string;
 }
 /**
- * One row of GET /v1/orders?user=...'s "orders" array -- the sweeper mints
- * one order per deposit detected at a standing address, so a single (user,
- * origin) pair can accumulate many of these over time. Amount fields are
- * smallest-unit base-10 integer strings, "" when not yet known.
+ * One row of GET /v1/orders?user=...'s "orders" array. A single order can
+ * aggregate several deposits made to the same reusable forwarder; `deposits[]`
+ * is the per-arrival identity. Amount fields are smallest-unit base-10 integer
+ * strings, "" when not yet known.
  */
 interface OrderSummary {
     orderId: string;
@@ -2057,7 +2057,8 @@ interface RelayClient {
      * GET /v1/deposit-address -- resolves the stable, reusable deposit
      * address for (user, originChainId, originCurrency). No amount is
      * involved and no order is created; the same address can receive any
-     * number of deposits of any size (each swept into its own order).
+     * number of deposits of any size. Several deposits can be aggregated into
+     * one order when they jointly fund the same reusable forwarder.
      *
      * `target` (Task 8) is the delivery asset's symbol from
      * `Catalog.targets` -- sent as `&target=<symbol>` only when it's a
@@ -2229,22 +2230,16 @@ interface RelayDepositProps extends RelayWalletProps {
      * watch `depositState` (phase/txHash/reverted) for those. Safe to treat as
      * "the funds moved" (upstream 83845fb). */
     onDeposited?: (txHash: string) => void;
-    /**
-     * Called once per NEW order the backend mints while step 2 (the deposit
-     * address) is showing — i.e. a deposit reached the address and the sweeper
-     * picked it up. This is the only success signal that exists for a MANUAL
-     * (QR / copied-address) deposit, which the widget cannot observe as a tx:
-     * `onDeposited` above fires only for the one-click path, on confirmation.
-     * Fires after the sweep (that is when the order is created), not at
-     * on-chain arrival. One-click deposits also arrive here once swept.
-     */
-    onDepositDetected?: (order: OrderSummary) => void;
     onError?: (error: Error) => void;
-    /** Called by the connect prompt shown above the form while there is neither a connected
-     * wallet nor a usable recipient (host-supplied or typed). Omitted — the prompt renders as
-     * text only, with no button. The form itself stays usable either way: typing a valid
-     * recipient is a supported, wallet-free path to a deposit address. */
+    /** Called by the `Connect Wallet` CTA under the locked card that stands in for the QR
+     * while there is neither a connected wallet nor a usable recipient (host-supplied or
+     * typed). Omitted — the locked card renders as text only, with no button. The rest of
+     * the screen stays usable either way: typing a valid recipient is a supported,
+     * wallet-free path to a deposit address. */
     onRequestConnect?: () => void;
+    /** @deprecated The Deposit footer entry was removed. Retained as a no-op
+     * compatibility prop so existing hosts do not need an immediate migration. */
+    onOpenHistory?: () => void;
     /** Extra class name(s) for the modal/drawer content element. */
     className?: string;
     theme?: RelayTheme;
@@ -2364,7 +2359,7 @@ interface RelayDepositContentProps {
     className?: string;
 }
 /**
- * `<RelayDeposit.Content>` — the modal/drawer surface. The wizard body is a
+ * `<RelayDeposit.Content>` — the modal/drawer surface. The deposit body is a
  * child of `ShellContent`, i.e. of radix's `Dialog.Portal` / vaul's
  * `Drawer.Portal`, which render nothing while closed. The state it renders is
  * NOT its own any more: `<RelayDeposit>` mounts the wizard engine above the

package/dist/index.d.ts

@@ -1890,10 +1890,10 @@ interface DepositAddressResult {
     originCurrency: string;
 }
 /**
- * One row of GET /v1/orders?user=...'s "orders" array -- the sweeper mints
- * one order per deposit detected at a standing address, so a single (user,
- * origin) pair can accumulate many of these over time. Amount fields are
- * smallest-unit base-10 integer strings, "" when not yet known.
+ * One row of GET /v1/orders?user=...'s "orders" array. A single order can
+ * aggregate several deposits made to the same reusable forwarder; `deposits[]`
+ * is the per-arrival identity. Amount fields are smallest-unit base-10 integer
+ * strings, "" when not yet known.
  */
 interface OrderSummary {
     orderId: string;
@@ -2057,7 +2057,8 @@ interface RelayClient {
      * GET /v1/deposit-address -- resolves the stable, reusable deposit
      * address for (user, originChainId, originCurrency). No amount is
      * involved and no order is created; the same address can receive any
-     * number of deposits of any size (each swept into its own order).
+     * number of deposits of any size. Several deposits can be aggregated into
+     * one order when they jointly fund the same reusable forwarder.
      *
      * `target` (Task 8) is the delivery asset's symbol from
      * `Catalog.targets` -- sent as `&target=<symbol>` only when it's a
@@ -2229,22 +2230,16 @@ interface RelayDepositProps extends RelayWalletProps {
      * watch `depositState` (phase/txHash/reverted) for those. Safe to treat as
      * "the funds moved" (upstream 83845fb). */
     onDeposited?: (txHash: string) => void;
-    /**
-     * Called once per NEW order the backend mints while step 2 (the deposit
-     * address) is showing — i.e. a deposit reached the address and the sweeper
-     * picked it up. This is the only success signal that exists for a MANUAL
-     * (QR / copied-address) deposit, which the widget cannot observe as a tx:
-     * `onDeposited` above fires only for the one-click path, on confirmation.
-     * Fires after the sweep (that is when the order is created), not at
-     * on-chain arrival. One-click deposits also arrive here once swept.
-     */
-    onDepositDetected?: (order: OrderSummary) => void;
     onError?: (error: Error) => void;
-    /** Called by the connect prompt shown above the form while there is neither a connected
-     * wallet nor a usable recipient (host-supplied or typed). Omitted — the prompt renders as
-     * text only, with no button. The form itself stays usable either way: typing a valid
-     * recipient is a supported, wallet-free path to a deposit address. */
+    /** Called by the `Connect Wallet` CTA under the locked card that stands in for the QR
+     * while there is neither a connected wallet nor a usable recipient (host-supplied or
+     * typed). Omitted — the locked card renders as text only, with no button. The rest of
+     * the screen stays usable either way: typing a valid recipient is a supported,
+     * wallet-free path to a deposit address. */
     onRequestConnect?: () => void;
+    /** @deprecated The Deposit footer entry was removed. Retained as a no-op
+     * compatibility prop so existing hosts do not need an immediate migration. */
+    onOpenHistory?: () => void;
     /** Extra class name(s) for the modal/drawer content element. */
     className?: string;
     theme?: RelayTheme;
@@ -2364,7 +2359,7 @@ interface RelayDepositContentProps {
     className?: string;
 }
 /**
- * `<RelayDeposit.Content>` — the modal/drawer surface. The wizard body is a
+ * `<RelayDeposit.Content>` — the modal/drawer surface. The deposit body is a
  * child of `ShellContent`, i.e. of radix's `Dialog.Portal` / vaul's
  * `Drawer.Portal`, which render nothing while closed. The state it renders is
  * NOT its own any more: `<RelayDeposit>` mounts the wizard engine above the