arcy.js 0.0.2 → 0.1.0
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.
- package/README.md +94 -3
- package/dist/arcy.chat.ab181cf5a84b.js +1258 -0
- package/dist/arcy.flow.fef131718e42.js +3 -0
- package/dist/arcy.legacy.ab4e9266b657.js +567 -0
- package/dist/arcy.loader.js +2 -0
- package/dist/arcy.modern.60faeffc62a2.js +567 -0
- package/dist/arcy.picker.c598a581d964.js +59 -0
- package/dist/design-mode.cjs +135 -0
- package/dist/design-mode.d.cts +197 -0
- package/dist/design-mode.d.ts +197 -0
- package/dist/design-mode.js +127 -0
- package/dist/fonts/dm-sans-latin-ext.woff2 +0 -0
- package/dist/fonts/dm-sans-latin.woff2 +0 -0
- package/dist/fonts/ibm-plex-sans-latin-ext.woff2 +0 -0
- package/dist/fonts/ibm-plex-sans-latin.woff2 +0 -0
- package/dist/fonts/inter-latin-ext.woff2 +0 -0
- package/dist/fonts/inter-latin.woff2 +0 -0
- package/dist/fonts/lato-latin-ext.woff2 +0 -0
- package/dist/fonts/lato-latin.woff2 +0 -0
- package/dist/fonts/manrope-latin-ext.woff2 +0 -0
- package/dist/fonts/manrope-latin.woff2 +0 -0
- package/dist/fonts/montserrat-latin-ext.woff2 +0 -0
- package/dist/fonts/montserrat-latin.woff2 +0 -0
- package/dist/fonts/nunito-latin-ext.woff2 +0 -0
- package/dist/fonts/nunito-latin.woff2 +0 -0
- package/dist/fonts/open-sans-latin-ext.woff2 +0 -0
- package/dist/fonts/open-sans-latin.woff2 +0 -0
- package/dist/fonts/playfair-display-latin-ext.woff2 +0 -0
- package/dist/fonts/playfair-display-latin.woff2 +0 -0
- package/dist/fonts/poppins-latin-ext.woff2 +0 -0
- package/dist/fonts/poppins-latin.woff2 +0 -0
- package/dist/fonts/roboto-latin-ext.woff2 +0 -0
- package/dist/fonts/roboto-latin.woff2 +0 -0
- package/dist/fonts/source-sans-3-latin-ext.woff2 +0 -0
- package/dist/fonts/source-sans-3-latin.woff2 +0 -0
- package/dist/fonts/work-sans-latin-ext.woff2 +0 -0
- package/dist/fonts/work-sans-latin.woff2 +0 -0
- package/dist/index.cjs +5114 -0
- package/dist/index.d.cts +133 -0
- package/dist/index.d.ts +133 -0
- package/dist/index.js +5109 -0
- package/dist/snippet.cjs +46 -0
- package/dist/snippet.d.cts +39 -0
- package/dist/snippet.d.ts +39 -0
- package/dist/snippet.js +43 -0
- package/package.json +69 -5
- package/index.js +0 -5
package/dist/index.d.cts
ADDED
|
@@ -0,0 +1,133 @@
|
|
|
1
|
+
/**
|
|
2
|
+
* The three widget lifecycle events, and deliberately only three
|
|
3
|
+
* (PRODUCT_SCOPE §1.1, ADR 0050).
|
|
4
|
+
*
|
|
5
|
+
* `message` and the flow events are absent on purpose: they belong to
|
|
6
|
+
* subsystems that do not exist yet, and publishing an event name promises a
|
|
7
|
+
* contract before the thing that fires it is built. A host app that wires a
|
|
8
|
+
* handler and gets silence has been lied to. Adding an event later is additive.
|
|
9
|
+
*/
|
|
10
|
+
type ArcyEvent = "ready" | "open" | "close";
|
|
11
|
+
type ArcyEventHandler = () => void;
|
|
12
|
+
/** The function `on()` hands back. Calling it removes that one handler. */
|
|
13
|
+
type Unsubscribe = () => void;
|
|
14
|
+
/**
|
|
15
|
+
* What an attribute value may be. Mirrors the five trait data types the backend
|
|
16
|
+
* registry accepts (PRODUCT_SCOPE §9.1.5), plus `null`, which clears the key
|
|
17
|
+
* and is the only value that does.
|
|
18
|
+
*
|
|
19
|
+
* Typing is enforced server-side against the declared trait, not here: the
|
|
20
|
+
* widget cannot know what an app has declared, and validating twice with one
|
|
21
|
+
* side guessing produces disagreements that are worse than no check at all.
|
|
22
|
+
*/
|
|
23
|
+
type AttributeValue = string | number | boolean | null | string[];
|
|
24
|
+
type Attributes = Record<string, AttributeValue>;
|
|
25
|
+
/**
|
|
26
|
+
* The complete set of `init()` options, and it is complete by design
|
|
27
|
+
* (PRODUCT_SCOPE §11.5.1, resolved at G1 as Q41). **Reopened once, D733**
|
|
28
|
+
* (PRD 11, slice 11.8): `contentLocale` was added as the fourth and only
|
|
29
|
+
* other deliberate exception, for the same reason as the original three - it
|
|
30
|
+
* is a runtime escape hatch the dashboard cannot know about, not
|
|
31
|
+
* configuration moved to the wrong side of the boundary. See `contentLocale`
|
|
32
|
+
* below for why it is a separate option from `locale` rather than a second
|
|
33
|
+
* code shape on the same one.
|
|
34
|
+
*
|
|
35
|
+
* Configuration is authored in the dashboard. These four are runtime escape
|
|
36
|
+
* hatches for things the dashboard structurally cannot know, and the dashboard
|
|
37
|
+
* shows an "Overridden in code" badge when one is sent. Anything a
|
|
38
|
+
* non-developer would want to change belongs in the dashboard, where they can
|
|
39
|
+
* actually reach it. **Do not add a fifth without reopening Q41.**
|
|
40
|
+
*/
|
|
41
|
+
interface ArcyOptions {
|
|
42
|
+
/** Consent signal for behavioral telemetry. A cookie banner is code. */
|
|
43
|
+
telemetry?: boolean;
|
|
44
|
+
/**
|
|
45
|
+
* The host app usually knows the user's language before ARCY loads.
|
|
46
|
+
*
|
|
47
|
+
* Two-letter codes only (`"en"`/`"tr"`). This feeds `SdkApp.uiLanguage`,
|
|
48
|
+
* the agent's default reply-language directive (D691) - it does **not**
|
|
49
|
+
* set the session's content locale. See `contentLocale` for that, a
|
|
50
|
+
* deliberately separate option (D732, D733): the two shapes (`"en"` vs.
|
|
51
|
+
* `"en-US"`) are ambiguous on one option, and a customer whose
|
|
52
|
+
* reply-language default and content locale genuinely differ (an
|
|
53
|
+
* English-replying agent serving a `tr-TR` audience, or vice versa) needs
|
|
54
|
+
* to be able to set them independently.
|
|
55
|
+
*/
|
|
56
|
+
locale?: string;
|
|
57
|
+
/** A support page wanting the panel open on arrival is a real, narrow case. */
|
|
58
|
+
defaultOpen?: boolean;
|
|
59
|
+
/**
|
|
60
|
+
* The end user's content locale (PRD 11, slice 11.8; ADR 0049, D733).
|
|
61
|
+
*
|
|
62
|
+
* Region-qualified (`"en-US"`/`"tr-TR"`, the `LocaleCode` catalogue from
|
|
63
|
+
* the backend's `locale-catalog.ts`), unlike `locale` above. Seeds
|
|
64
|
+
* `SdkSession.localeCode`'s explicit tier at bootstrap time - the same
|
|
65
|
+
* tier a `locale_code` identify()/updateUser() trait fills (§1.1's install
|
|
66
|
+
* snippet). **Not auto-derived from `locale`, deliberately (D733):** that
|
|
67
|
+
* would silently guess a customer's audience region from their reply
|
|
68
|
+
* language, which is wrong exactly when the two are set independently for
|
|
69
|
+
* a real reason. Pass both when both are known; pass neither and the
|
|
70
|
+
* chain falls through to the browser language, then the app default.
|
|
71
|
+
*/
|
|
72
|
+
contentLocale?: string;
|
|
73
|
+
}
|
|
74
|
+
/**
|
|
75
|
+
* The namespace object: `window.arcy` in the HTML build, the default export in
|
|
76
|
+
* the npm build. Both paths resolve to the same object so a call written
|
|
77
|
+
* against one behaves identically on the other.
|
|
78
|
+
*
|
|
79
|
+
* **No method throws and no promise rejects** (ADR 0050). Async methods resolve
|
|
80
|
+
* even on failure and report through a console warning. A rejected promise
|
|
81
|
+
* nobody awaited surfaces as an unhandled rejection inside the customer's error
|
|
82
|
+
* reporting, attributed to them, and the documented install snippet calls
|
|
83
|
+
* `identify()` with no `await`.
|
|
84
|
+
*/
|
|
85
|
+
/**
|
|
86
|
+
* The third argument to `identify()` (slice 6.3, D158).
|
|
87
|
+
*
|
|
88
|
+
* **An options object rather than a positional third parameter**, because
|
|
89
|
+
* ADR 0050 froze this API and a frozen API published on customer pages is
|
|
90
|
+
* exactly where positional arguments accumulate into
|
|
91
|
+
* `identify(id, traits, hash, null, true)` with no way to fix it. Four extra
|
|
92
|
+
* characters in the copy-paste recipe buys extensibility on the one surface
|
|
93
|
+
* that cannot be revised.
|
|
94
|
+
*/
|
|
95
|
+
interface IdentifyOptions {
|
|
96
|
+
/**
|
|
97
|
+
* `HMAC-SHA256(environment Secret, userId)`, computed on the customer's own
|
|
98
|
+
* server and never in the browser (PRD 6, D152).
|
|
99
|
+
*
|
|
100
|
+
* The name is Intercom's and Segment's, so the install recipe reads as
|
|
101
|
+
* familiar rather than novel. Optional, and strongly recommended: with
|
|
102
|
+
* identity verification off it is recorded and changes nothing, and with it
|
|
103
|
+
* on an unproven identity degrades to anonymous rather than being trusted.
|
|
104
|
+
*/
|
|
105
|
+
userHash?: string;
|
|
106
|
+
}
|
|
107
|
+
interface Arcy {
|
|
108
|
+
init(token: string, options?: ArcyOptions): Promise<void>;
|
|
109
|
+
identify(userId: string, attributes?: Attributes, options?: IdentifyOptions): Promise<void>;
|
|
110
|
+
identifyAnonymous(attributes?: Attributes): Promise<void>;
|
|
111
|
+
updateUser(attributes?: Attributes): Promise<void>;
|
|
112
|
+
reset(): void;
|
|
113
|
+
open(): void;
|
|
114
|
+
close(): void;
|
|
115
|
+
on(event: ArcyEvent, handler: ArcyEventHandler): Unsubscribe;
|
|
116
|
+
readonly VERSION: string;
|
|
117
|
+
}
|
|
118
|
+
|
|
119
|
+
/**
|
|
120
|
+
* Kept as a plain literal rather than injected from package.json at build time,
|
|
121
|
+
* so the ESM, CJS, and IIFE builds all carry the same value with no build-time
|
|
122
|
+
* indirection. Bumped with the package version.
|
|
123
|
+
*/
|
|
124
|
+
declare const VERSION = "0.1.0";
|
|
125
|
+
|
|
126
|
+
/**
|
|
127
|
+
* The namespace object. In the HTML build this is what `window.arcy` is; in
|
|
128
|
+
* the npm build it is the default export. Both builds resolve to the same
|
|
129
|
+
* object so a call written against one path behaves identically on the other.
|
|
130
|
+
*/
|
|
131
|
+
declare const arcy: Arcy;
|
|
132
|
+
|
|
133
|
+
export { type Arcy, type ArcyEvent, type ArcyEventHandler, type ArcyOptions, type AttributeValue, type Attributes, type Unsubscribe, VERSION, arcy as default };
|
package/dist/index.d.ts
ADDED
|
@@ -0,0 +1,133 @@
|
|
|
1
|
+
/**
|
|
2
|
+
* The three widget lifecycle events, and deliberately only three
|
|
3
|
+
* (PRODUCT_SCOPE §1.1, ADR 0050).
|
|
4
|
+
*
|
|
5
|
+
* `message` and the flow events are absent on purpose: they belong to
|
|
6
|
+
* subsystems that do not exist yet, and publishing an event name promises a
|
|
7
|
+
* contract before the thing that fires it is built. A host app that wires a
|
|
8
|
+
* handler and gets silence has been lied to. Adding an event later is additive.
|
|
9
|
+
*/
|
|
10
|
+
type ArcyEvent = "ready" | "open" | "close";
|
|
11
|
+
type ArcyEventHandler = () => void;
|
|
12
|
+
/** The function `on()` hands back. Calling it removes that one handler. */
|
|
13
|
+
type Unsubscribe = () => void;
|
|
14
|
+
/**
|
|
15
|
+
* What an attribute value may be. Mirrors the five trait data types the backend
|
|
16
|
+
* registry accepts (PRODUCT_SCOPE §9.1.5), plus `null`, which clears the key
|
|
17
|
+
* and is the only value that does.
|
|
18
|
+
*
|
|
19
|
+
* Typing is enforced server-side against the declared trait, not here: the
|
|
20
|
+
* widget cannot know what an app has declared, and validating twice with one
|
|
21
|
+
* side guessing produces disagreements that are worse than no check at all.
|
|
22
|
+
*/
|
|
23
|
+
type AttributeValue = string | number | boolean | null | string[];
|
|
24
|
+
type Attributes = Record<string, AttributeValue>;
|
|
25
|
+
/**
|
|
26
|
+
* The complete set of `init()` options, and it is complete by design
|
|
27
|
+
* (PRODUCT_SCOPE §11.5.1, resolved at G1 as Q41). **Reopened once, D733**
|
|
28
|
+
* (PRD 11, slice 11.8): `contentLocale` was added as the fourth and only
|
|
29
|
+
* other deliberate exception, for the same reason as the original three - it
|
|
30
|
+
* is a runtime escape hatch the dashboard cannot know about, not
|
|
31
|
+
* configuration moved to the wrong side of the boundary. See `contentLocale`
|
|
32
|
+
* below for why it is a separate option from `locale` rather than a second
|
|
33
|
+
* code shape on the same one.
|
|
34
|
+
*
|
|
35
|
+
* Configuration is authored in the dashboard. These four are runtime escape
|
|
36
|
+
* hatches for things the dashboard structurally cannot know, and the dashboard
|
|
37
|
+
* shows an "Overridden in code" badge when one is sent. Anything a
|
|
38
|
+
* non-developer would want to change belongs in the dashboard, where they can
|
|
39
|
+
* actually reach it. **Do not add a fifth without reopening Q41.**
|
|
40
|
+
*/
|
|
41
|
+
interface ArcyOptions {
|
|
42
|
+
/** Consent signal for behavioral telemetry. A cookie banner is code. */
|
|
43
|
+
telemetry?: boolean;
|
|
44
|
+
/**
|
|
45
|
+
* The host app usually knows the user's language before ARCY loads.
|
|
46
|
+
*
|
|
47
|
+
* Two-letter codes only (`"en"`/`"tr"`). This feeds `SdkApp.uiLanguage`,
|
|
48
|
+
* the agent's default reply-language directive (D691) - it does **not**
|
|
49
|
+
* set the session's content locale. See `contentLocale` for that, a
|
|
50
|
+
* deliberately separate option (D732, D733): the two shapes (`"en"` vs.
|
|
51
|
+
* `"en-US"`) are ambiguous on one option, and a customer whose
|
|
52
|
+
* reply-language default and content locale genuinely differ (an
|
|
53
|
+
* English-replying agent serving a `tr-TR` audience, or vice versa) needs
|
|
54
|
+
* to be able to set them independently.
|
|
55
|
+
*/
|
|
56
|
+
locale?: string;
|
|
57
|
+
/** A support page wanting the panel open on arrival is a real, narrow case. */
|
|
58
|
+
defaultOpen?: boolean;
|
|
59
|
+
/**
|
|
60
|
+
* The end user's content locale (PRD 11, slice 11.8; ADR 0049, D733).
|
|
61
|
+
*
|
|
62
|
+
* Region-qualified (`"en-US"`/`"tr-TR"`, the `LocaleCode` catalogue from
|
|
63
|
+
* the backend's `locale-catalog.ts`), unlike `locale` above. Seeds
|
|
64
|
+
* `SdkSession.localeCode`'s explicit tier at bootstrap time - the same
|
|
65
|
+
* tier a `locale_code` identify()/updateUser() trait fills (§1.1's install
|
|
66
|
+
* snippet). **Not auto-derived from `locale`, deliberately (D733):** that
|
|
67
|
+
* would silently guess a customer's audience region from their reply
|
|
68
|
+
* language, which is wrong exactly when the two are set independently for
|
|
69
|
+
* a real reason. Pass both when both are known; pass neither and the
|
|
70
|
+
* chain falls through to the browser language, then the app default.
|
|
71
|
+
*/
|
|
72
|
+
contentLocale?: string;
|
|
73
|
+
}
|
|
74
|
+
/**
|
|
75
|
+
* The namespace object: `window.arcy` in the HTML build, the default export in
|
|
76
|
+
* the npm build. Both paths resolve to the same object so a call written
|
|
77
|
+
* against one behaves identically on the other.
|
|
78
|
+
*
|
|
79
|
+
* **No method throws and no promise rejects** (ADR 0050). Async methods resolve
|
|
80
|
+
* even on failure and report through a console warning. A rejected promise
|
|
81
|
+
* nobody awaited surfaces as an unhandled rejection inside the customer's error
|
|
82
|
+
* reporting, attributed to them, and the documented install snippet calls
|
|
83
|
+
* `identify()` with no `await`.
|
|
84
|
+
*/
|
|
85
|
+
/**
|
|
86
|
+
* The third argument to `identify()` (slice 6.3, D158).
|
|
87
|
+
*
|
|
88
|
+
* **An options object rather than a positional third parameter**, because
|
|
89
|
+
* ADR 0050 froze this API and a frozen API published on customer pages is
|
|
90
|
+
* exactly where positional arguments accumulate into
|
|
91
|
+
* `identify(id, traits, hash, null, true)` with no way to fix it. Four extra
|
|
92
|
+
* characters in the copy-paste recipe buys extensibility on the one surface
|
|
93
|
+
* that cannot be revised.
|
|
94
|
+
*/
|
|
95
|
+
interface IdentifyOptions {
|
|
96
|
+
/**
|
|
97
|
+
* `HMAC-SHA256(environment Secret, userId)`, computed on the customer's own
|
|
98
|
+
* server and never in the browser (PRD 6, D152).
|
|
99
|
+
*
|
|
100
|
+
* The name is Intercom's and Segment's, so the install recipe reads as
|
|
101
|
+
* familiar rather than novel. Optional, and strongly recommended: with
|
|
102
|
+
* identity verification off it is recorded and changes nothing, and with it
|
|
103
|
+
* on an unproven identity degrades to anonymous rather than being trusted.
|
|
104
|
+
*/
|
|
105
|
+
userHash?: string;
|
|
106
|
+
}
|
|
107
|
+
interface Arcy {
|
|
108
|
+
init(token: string, options?: ArcyOptions): Promise<void>;
|
|
109
|
+
identify(userId: string, attributes?: Attributes, options?: IdentifyOptions): Promise<void>;
|
|
110
|
+
identifyAnonymous(attributes?: Attributes): Promise<void>;
|
|
111
|
+
updateUser(attributes?: Attributes): Promise<void>;
|
|
112
|
+
reset(): void;
|
|
113
|
+
open(): void;
|
|
114
|
+
close(): void;
|
|
115
|
+
on(event: ArcyEvent, handler: ArcyEventHandler): Unsubscribe;
|
|
116
|
+
readonly VERSION: string;
|
|
117
|
+
}
|
|
118
|
+
|
|
119
|
+
/**
|
|
120
|
+
* Kept as a plain literal rather than injected from package.json at build time,
|
|
121
|
+
* so the ESM, CJS, and IIFE builds all carry the same value with no build-time
|
|
122
|
+
* indirection. Bumped with the package version.
|
|
123
|
+
*/
|
|
124
|
+
declare const VERSION = "0.1.0";
|
|
125
|
+
|
|
126
|
+
/**
|
|
127
|
+
* The namespace object. In the HTML build this is what `window.arcy` is; in
|
|
128
|
+
* the npm build it is the default export. Both builds resolve to the same
|
|
129
|
+
* object so a call written against one path behaves identically on the other.
|
|
130
|
+
*/
|
|
131
|
+
declare const arcy: Arcy;
|
|
132
|
+
|
|
133
|
+
export { type Arcy, type ArcyEvent, type ArcyEventHandler, type ArcyOptions, type AttributeValue, type Attributes, type Unsubscribe, VERSION, arcy as default };
|