@swishapp/sdk 0.149.0 → 0.149.1-unstable.20260917131745
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
|
@@ -2,6 +2,13 @@ export interface AjaxConfig {
|
|
|
2
2
|
storeDomain: string;
|
|
3
3
|
fetch?: (input: string | URL | Request, init?: RequestInit) => Promise<Response>;
|
|
4
4
|
responseInterceptor?: (response: Response, request: Request) => Promise<void> | void;
|
|
5
|
+
/**
|
|
6
|
+
* Called as a request is dispatched, before any response exists. Returning a
|
|
7
|
+
* function marks that request as in flight; the returned function is called
|
|
8
|
+
* once its response has been fully processed, or once the request has failed,
|
|
9
|
+
* so a consumer can hold state for the whole round trip.
|
|
10
|
+
*/
|
|
11
|
+
requestInterceptor?: (request: Request) => (() => void) | void;
|
|
5
12
|
}
|
|
6
13
|
export interface CartLineItem {
|
|
7
14
|
id: number;
|
|
@@ -91,8 +98,8 @@ export interface CartChangeItem {
|
|
|
91
98
|
view_key: string;
|
|
92
99
|
}
|
|
93
100
|
export interface CartChangeResponse extends Cart {
|
|
94
|
-
items_added
|
|
95
|
-
items_removed
|
|
101
|
+
items_added?: CartChangeItem[];
|
|
102
|
+
items_removed?: CartChangeItem[];
|
|
96
103
|
discount_codes: any[];
|
|
97
104
|
}
|
|
98
105
|
export interface CartError {
|
|
@@ -3,10 +3,59 @@ export declare class AjaxApiPublisher {
|
|
|
3
3
|
private readonly eventBus;
|
|
4
4
|
private readonly eventMap;
|
|
5
5
|
private previousCart;
|
|
6
|
+
private pendingCartMutations;
|
|
6
7
|
constructor(eventBus: EventBus);
|
|
8
|
+
/**
|
|
9
|
+
* Registers a cart mutation as in flight from the moment it is dispatched
|
|
10
|
+
* until its response has been processed, and returns the function that
|
|
11
|
+
* clears it. Requests that are not cart mutations are ignored.
|
|
12
|
+
*
|
|
13
|
+
* This is what stops a plain `/cart.js` read that resolves mid-mutation from
|
|
14
|
+
* replacing the snapshot the mutation will be diffed against — see
|
|
15
|
+
* `snapshotCart` and SWI-2836.
|
|
16
|
+
*/
|
|
17
|
+
beginRequest(request: Request): (() => void) | void;
|
|
7
18
|
processFetchResponse(response: Response, request: Request): Promise<void>;
|
|
8
19
|
getEventName(url: string): EventName | null;
|
|
20
|
+
/**
|
|
21
|
+
* A cart read that resolves while a mutation is in flight can already reflect
|
|
22
|
+
* that mutation, and adopting it would leave the mutation diffing against a
|
|
23
|
+
* cart the removal has happened in — nothing looks removed. The mutation's
|
|
24
|
+
* own response is the next snapshot; reads wait their turn.
|
|
25
|
+
*
|
|
26
|
+
* `/cart/change.js` no longer depends on this, since `diffRemovedItems` reads
|
|
27
|
+
* Shopify's `items_removed` first. `/cart/update.js` has no such field, so
|
|
28
|
+
* the snapshot is all it has.
|
|
29
|
+
*/
|
|
9
30
|
private snapshotCart;
|
|
31
|
+
/**
|
|
32
|
+
* `/cart/change.js` reports its own removals in `items_removed`, so that is
|
|
33
|
+
* the authoritative answer and it is read first.
|
|
34
|
+
*
|
|
35
|
+
* Leading with the snapshot diff instead loses the removal whenever another
|
|
36
|
+
* script's `/cart.js` read lands between the removal request and its response
|
|
37
|
+
* (an abandoned-cart app polling the cart is enough): `snapshotCart` has
|
|
38
|
+
* already replaced `previousCart` with the post-removal cart, so the diff
|
|
39
|
+
* finds nothing gone and the shopper is never offered the save — SWI-2836.
|
|
40
|
+
*
|
|
41
|
+
* `/cart/update.js` omits the field entirely, so an *absent* `items_removed`
|
|
42
|
+
* is what selects the snapshot diff. An empty array is Shopify telling us
|
|
43
|
+
* nothing was removed, and is not second-guessed.
|
|
44
|
+
*
|
|
45
|
+
* Both branches match on the cart line, never on `variant_id`. Shopify lists
|
|
46
|
+
* a quantity *decrease* in `items_removed` too, naming the line that survived
|
|
47
|
+
* it; a line the shopper deleted names a line the cart no longer has. Keying
|
|
48
|
+
* off `variant_id` instead drops a deleted line whenever another line still
|
|
49
|
+
* holds that variant — two lines of one variant separated by line item
|
|
50
|
+
* properties (gift wrap, engraving, a selling plan) — and the shopper is
|
|
51
|
+
* offered nothing for a deletion they just made.
|
|
52
|
+
*
|
|
53
|
+
* Verified against the live Ajax API (2026-09-16): an `items_removed` entry
|
|
54
|
+
* carries the line key as `view_key` and has no `key` of its own, and a
|
|
55
|
+
* 2 → 1 quantity change reports the surviving line's key there.
|
|
56
|
+
* `/cart/update.js` returns no `items_removed`, and its `items_changelog`
|
|
57
|
+
* carries `added` only — the snapshot really is all that path has.
|
|
58
|
+
*/
|
|
10
59
|
private diffRemovedItems;
|
|
11
60
|
private toCartChangeItem;
|
|
12
61
|
}
|