@guideify/react 0.2.0 → 0.4.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/dist/index.d.cts +159 -0
- package/dist/index.d.ts +159 -0
- package/package.json +1 -1
package/dist/index.d.cts
CHANGED
|
@@ -184,8 +184,144 @@ interface Flow {
|
|
|
184
184
|
priority?: number;
|
|
185
185
|
/** Can the end user close this flow? Use false sparingly. */
|
|
186
186
|
dismissible?: boolean;
|
|
187
|
+
/**
|
|
188
|
+
* The window the flow may start in — J-04. ISO 8601 instants; either end may
|
|
189
|
+
* be open. Judged by the SDK against the end user's clock at the moment it
|
|
190
|
+
* would start, so a flow turns on and off without a republish; a tour
|
|
191
|
+
* already running when `endsAt` passes is allowed to finish.
|
|
192
|
+
*/
|
|
193
|
+
startsAt?: string;
|
|
194
|
+
endsAt?: string;
|
|
195
|
+
/**
|
|
196
|
+
* A banner, slideout or hotspot instead of a tour — J-03. A flow with a
|
|
197
|
+
* surface carries `steps: []`, and that is the design rather than a
|
|
198
|
+
* placeholder: every core that predates surfaces drops a flow with no
|
|
199
|
+
* steps, so an environment pinned to one (R-04) skips the flow instead of
|
|
200
|
+
* drawing a banner as a blocking modal. `docs/ANNOUNCEMENTS_PLAN.md` §1.
|
|
201
|
+
*/
|
|
202
|
+
surface?: Surface;
|
|
187
203
|
steps: Step[];
|
|
188
204
|
}
|
|
205
|
+
/**
|
|
206
|
+
* One non-blocking message — J-03. `content` is a step's document, so the
|
|
207
|
+
* renderer and the editor are the tour's own.
|
|
208
|
+
*/
|
|
209
|
+
type Surface = {
|
|
210
|
+
type: 'banner';
|
|
211
|
+
content: StepContent;
|
|
212
|
+
position?: 'top' | 'bottom';
|
|
213
|
+
} | {
|
|
214
|
+
type: 'slideout';
|
|
215
|
+
content: StepContent;
|
|
216
|
+
corner?: 'bottom-end' | 'bottom-start';
|
|
217
|
+
} | {
|
|
218
|
+
type: 'hotspot';
|
|
219
|
+
content: StepContent;
|
|
220
|
+
target: ElementFingerprint;
|
|
221
|
+
};
|
|
222
|
+
/**
|
|
223
|
+
* What marks a checklist item done.
|
|
224
|
+
*
|
|
225
|
+
* A flow this environment already publishes, or an event the customer already
|
|
226
|
+
* sends us — both of which exist before the checklist does. There is
|
|
227
|
+
* deliberately no third variant for "the user ticked it": the surface is only
|
|
228
|
+
* worth its corner of somebody's application if it reflects what has actually
|
|
229
|
+
* happened in the product, and a box you can tick yourself reports nothing.
|
|
230
|
+
*/
|
|
231
|
+
type ChecklistItemGoal = {
|
|
232
|
+
type: 'flow';
|
|
233
|
+
flowId: string;
|
|
234
|
+
} | {
|
|
235
|
+
type: 'event';
|
|
236
|
+
name: string;
|
|
237
|
+
};
|
|
238
|
+
interface ChecklistItem {
|
|
239
|
+
id: string;
|
|
240
|
+
label: string;
|
|
241
|
+
/** Optional one-liner under the label. The renderer's document, not a string. */
|
|
242
|
+
body?: ContentNode;
|
|
243
|
+
goal: ChecklistItemGoal;
|
|
244
|
+
}
|
|
245
|
+
/**
|
|
246
|
+
* The persistent surface — BUILD_REPORT §8, J-02.
|
|
247
|
+
*
|
|
248
|
+
* **It carries no `trigger`, no `frequency` and no `priority`, and the three
|
|
249
|
+
* absences are the design.** A checklist is not triggered, it is present:
|
|
250
|
+
* `Trigger`'s five variants each describe a moment, which is precisely what
|
|
251
|
+
* this is not, and `Frequency` answers *how often does this fire* about
|
|
252
|
+
* something that never fires. It does not compete for the screen either — §8
|
|
253
|
+
* puts it outside the one-blocking-flow rule, so it never enters the sort that
|
|
254
|
+
* `priority` exists to break. Three fields pinned to a constant would each be a
|
|
255
|
+
* question the reader has to answer before discovering it was never asked.
|
|
256
|
+
*
|
|
257
|
+
* `audience` is the same `RuleNode` a flow takes, read by the same
|
|
258
|
+
* `evaluateRules`. Reusing the evaluator is what stops a second rule engine
|
|
259
|
+
* existing.
|
|
260
|
+
*/
|
|
261
|
+
interface Checklist {
|
|
262
|
+
id: string;
|
|
263
|
+
name: string;
|
|
264
|
+
version: number;
|
|
265
|
+
audience?: RuleNode;
|
|
266
|
+
items: ChecklistItem[];
|
|
267
|
+
/** Where the launcher sits. The host app's other corner is usually taken. */
|
|
268
|
+
position?: 'bottom-end' | 'bottom-start';
|
|
269
|
+
/** Hidden once every item is done, which is the default a customer expects. */
|
|
270
|
+
dismissWhenComplete?: boolean;
|
|
271
|
+
}
|
|
272
|
+
/**
|
|
273
|
+
* What pressing a resource entry does.
|
|
274
|
+
*
|
|
275
|
+
* A tour this environment already publishes, or a page the customer already
|
|
276
|
+
* keeps. There is deliberately no third variant holding an article: hosting
|
|
277
|
+
* help content is an editor, a search index and a second copy of documentation
|
|
278
|
+
* that already lives somewhere, and a variant can be added later where a CMS
|
|
279
|
+
* cannot be taken back out. RESOURCE_CENTRE_PLAN §2.1.
|
|
280
|
+
*
|
|
281
|
+
* `href` reaches an attribute, so whatever draws it passes it through
|
|
282
|
+
* `sanitizeUrl` first.
|
|
283
|
+
*/
|
|
284
|
+
type ResourceAction = {
|
|
285
|
+
type: 'flow';
|
|
286
|
+
flowId: string;
|
|
287
|
+
} | {
|
|
288
|
+
type: 'link';
|
|
289
|
+
href: string;
|
|
290
|
+
};
|
|
291
|
+
interface ResourceEntry {
|
|
292
|
+
id: string;
|
|
293
|
+
label: string;
|
|
294
|
+
/** Optional one-liner under the label. The renderer's document, not a string. */
|
|
295
|
+
body?: ContentNode;
|
|
296
|
+
action: ResourceAction;
|
|
297
|
+
}
|
|
298
|
+
interface ResourceSection {
|
|
299
|
+
id: string;
|
|
300
|
+
/** Absent on the one section of a centre that has no need to name its groups. */
|
|
301
|
+
title?: string;
|
|
302
|
+
entries: ResourceEntry[];
|
|
303
|
+
}
|
|
304
|
+
/**
|
|
305
|
+
* The always-on help surface — J-06.
|
|
306
|
+
*
|
|
307
|
+
* `Checklist`'s sibling, and the difference between them is the design: a
|
|
308
|
+
* checklist item is **completed by evidence**, once, and a resource entry is
|
|
309
|
+
* **used**, any number of times. So there is no `goal` here and no done-state,
|
|
310
|
+
* and no `dismissWhenComplete`, because this does not complete — it is what is
|
|
311
|
+
* still in the corner after the checklist has taken itself away.
|
|
312
|
+
*
|
|
313
|
+
* No `trigger`, `frequency` or `priority`, for the three reasons `Checklist`
|
|
314
|
+
* gives. `position` is the launcher's and is shared with the checklist's; where
|
|
315
|
+
* both are published and disagree, the checklist's is drawn.
|
|
316
|
+
*/
|
|
317
|
+
interface ResourceCentre {
|
|
318
|
+
id: string;
|
|
319
|
+
name: string;
|
|
320
|
+
version: number;
|
|
321
|
+
audience?: RuleNode;
|
|
322
|
+
sections: ResourceSection[];
|
|
323
|
+
position?: 'bottom-end' | 'bottom-start';
|
|
324
|
+
}
|
|
189
325
|
interface ThemeTokens {
|
|
190
326
|
accent?: string;
|
|
191
327
|
scrim?: string;
|
|
@@ -203,6 +339,29 @@ interface GuideifyConfig {
|
|
|
203
339
|
envKey: string;
|
|
204
340
|
flows: Flow[];
|
|
205
341
|
settings?: ConfigSettings;
|
|
342
|
+
/**
|
|
343
|
+
* The one persistent surface this environment publishes, if it has one.
|
|
344
|
+
*
|
|
345
|
+
* **Singular, deliberately.** A corner of somebody else's application has
|
|
346
|
+
* room for one launcher; a list invites two of them fighting over the same
|
|
347
|
+
* 56 pixels, and nothing in this product could arbitrate between them.
|
|
348
|
+
*
|
|
349
|
+
* Additive with a safe default, which is the header's rule and is what makes
|
|
350
|
+
* it publishable to environments held on an older core by `sdkPin` (R-04): a
|
|
351
|
+
* core built before this field existed parses the artifact, ignores the key
|
|
352
|
+
* and runs its flows. `packages/sdk/test/checklist-config.test.mjs` pins
|
|
353
|
+
* that, because it is an accident of `validateConfig` until something asserts
|
|
354
|
+
* it.
|
|
355
|
+
*/
|
|
356
|
+
checklist?: Checklist;
|
|
357
|
+
/**
|
|
358
|
+
* The help surface behind the same launcher, if the environment has one.
|
|
359
|
+
*
|
|
360
|
+
* Additive on `checklist`'s argument, and pinned the same way:
|
|
361
|
+
* `packages/sdk/test/resources-config.test.mjs` asserts that a core which has
|
|
362
|
+
* never heard of the key ignores it and runs its flows.
|
|
363
|
+
*/
|
|
364
|
+
resources?: ResourceCentre;
|
|
206
365
|
}
|
|
207
366
|
interface UserTraits {
|
|
208
367
|
[key: string]: unknown;
|
package/dist/index.d.ts
CHANGED
|
@@ -184,8 +184,144 @@ interface Flow {
|
|
|
184
184
|
priority?: number;
|
|
185
185
|
/** Can the end user close this flow? Use false sparingly. */
|
|
186
186
|
dismissible?: boolean;
|
|
187
|
+
/**
|
|
188
|
+
* The window the flow may start in — J-04. ISO 8601 instants; either end may
|
|
189
|
+
* be open. Judged by the SDK against the end user's clock at the moment it
|
|
190
|
+
* would start, so a flow turns on and off without a republish; a tour
|
|
191
|
+
* already running when `endsAt` passes is allowed to finish.
|
|
192
|
+
*/
|
|
193
|
+
startsAt?: string;
|
|
194
|
+
endsAt?: string;
|
|
195
|
+
/**
|
|
196
|
+
* A banner, slideout or hotspot instead of a tour — J-03. A flow with a
|
|
197
|
+
* surface carries `steps: []`, and that is the design rather than a
|
|
198
|
+
* placeholder: every core that predates surfaces drops a flow with no
|
|
199
|
+
* steps, so an environment pinned to one (R-04) skips the flow instead of
|
|
200
|
+
* drawing a banner as a blocking modal. `docs/ANNOUNCEMENTS_PLAN.md` §1.
|
|
201
|
+
*/
|
|
202
|
+
surface?: Surface;
|
|
187
203
|
steps: Step[];
|
|
188
204
|
}
|
|
205
|
+
/**
|
|
206
|
+
* One non-blocking message — J-03. `content` is a step's document, so the
|
|
207
|
+
* renderer and the editor are the tour's own.
|
|
208
|
+
*/
|
|
209
|
+
type Surface = {
|
|
210
|
+
type: 'banner';
|
|
211
|
+
content: StepContent;
|
|
212
|
+
position?: 'top' | 'bottom';
|
|
213
|
+
} | {
|
|
214
|
+
type: 'slideout';
|
|
215
|
+
content: StepContent;
|
|
216
|
+
corner?: 'bottom-end' | 'bottom-start';
|
|
217
|
+
} | {
|
|
218
|
+
type: 'hotspot';
|
|
219
|
+
content: StepContent;
|
|
220
|
+
target: ElementFingerprint;
|
|
221
|
+
};
|
|
222
|
+
/**
|
|
223
|
+
* What marks a checklist item done.
|
|
224
|
+
*
|
|
225
|
+
* A flow this environment already publishes, or an event the customer already
|
|
226
|
+
* sends us — both of which exist before the checklist does. There is
|
|
227
|
+
* deliberately no third variant for "the user ticked it": the surface is only
|
|
228
|
+
* worth its corner of somebody's application if it reflects what has actually
|
|
229
|
+
* happened in the product, and a box you can tick yourself reports nothing.
|
|
230
|
+
*/
|
|
231
|
+
type ChecklistItemGoal = {
|
|
232
|
+
type: 'flow';
|
|
233
|
+
flowId: string;
|
|
234
|
+
} | {
|
|
235
|
+
type: 'event';
|
|
236
|
+
name: string;
|
|
237
|
+
};
|
|
238
|
+
interface ChecklistItem {
|
|
239
|
+
id: string;
|
|
240
|
+
label: string;
|
|
241
|
+
/** Optional one-liner under the label. The renderer's document, not a string. */
|
|
242
|
+
body?: ContentNode;
|
|
243
|
+
goal: ChecklistItemGoal;
|
|
244
|
+
}
|
|
245
|
+
/**
|
|
246
|
+
* The persistent surface — BUILD_REPORT §8, J-02.
|
|
247
|
+
*
|
|
248
|
+
* **It carries no `trigger`, no `frequency` and no `priority`, and the three
|
|
249
|
+
* absences are the design.** A checklist is not triggered, it is present:
|
|
250
|
+
* `Trigger`'s five variants each describe a moment, which is precisely what
|
|
251
|
+
* this is not, and `Frequency` answers *how often does this fire* about
|
|
252
|
+
* something that never fires. It does not compete for the screen either — §8
|
|
253
|
+
* puts it outside the one-blocking-flow rule, so it never enters the sort that
|
|
254
|
+
* `priority` exists to break. Three fields pinned to a constant would each be a
|
|
255
|
+
* question the reader has to answer before discovering it was never asked.
|
|
256
|
+
*
|
|
257
|
+
* `audience` is the same `RuleNode` a flow takes, read by the same
|
|
258
|
+
* `evaluateRules`. Reusing the evaluator is what stops a second rule engine
|
|
259
|
+
* existing.
|
|
260
|
+
*/
|
|
261
|
+
interface Checklist {
|
|
262
|
+
id: string;
|
|
263
|
+
name: string;
|
|
264
|
+
version: number;
|
|
265
|
+
audience?: RuleNode;
|
|
266
|
+
items: ChecklistItem[];
|
|
267
|
+
/** Where the launcher sits. The host app's other corner is usually taken. */
|
|
268
|
+
position?: 'bottom-end' | 'bottom-start';
|
|
269
|
+
/** Hidden once every item is done, which is the default a customer expects. */
|
|
270
|
+
dismissWhenComplete?: boolean;
|
|
271
|
+
}
|
|
272
|
+
/**
|
|
273
|
+
* What pressing a resource entry does.
|
|
274
|
+
*
|
|
275
|
+
* A tour this environment already publishes, or a page the customer already
|
|
276
|
+
* keeps. There is deliberately no third variant holding an article: hosting
|
|
277
|
+
* help content is an editor, a search index and a second copy of documentation
|
|
278
|
+
* that already lives somewhere, and a variant can be added later where a CMS
|
|
279
|
+
* cannot be taken back out. RESOURCE_CENTRE_PLAN §2.1.
|
|
280
|
+
*
|
|
281
|
+
* `href` reaches an attribute, so whatever draws it passes it through
|
|
282
|
+
* `sanitizeUrl` first.
|
|
283
|
+
*/
|
|
284
|
+
type ResourceAction = {
|
|
285
|
+
type: 'flow';
|
|
286
|
+
flowId: string;
|
|
287
|
+
} | {
|
|
288
|
+
type: 'link';
|
|
289
|
+
href: string;
|
|
290
|
+
};
|
|
291
|
+
interface ResourceEntry {
|
|
292
|
+
id: string;
|
|
293
|
+
label: string;
|
|
294
|
+
/** Optional one-liner under the label. The renderer's document, not a string. */
|
|
295
|
+
body?: ContentNode;
|
|
296
|
+
action: ResourceAction;
|
|
297
|
+
}
|
|
298
|
+
interface ResourceSection {
|
|
299
|
+
id: string;
|
|
300
|
+
/** Absent on the one section of a centre that has no need to name its groups. */
|
|
301
|
+
title?: string;
|
|
302
|
+
entries: ResourceEntry[];
|
|
303
|
+
}
|
|
304
|
+
/**
|
|
305
|
+
* The always-on help surface — J-06.
|
|
306
|
+
*
|
|
307
|
+
* `Checklist`'s sibling, and the difference between them is the design: a
|
|
308
|
+
* checklist item is **completed by evidence**, once, and a resource entry is
|
|
309
|
+
* **used**, any number of times. So there is no `goal` here and no done-state,
|
|
310
|
+
* and no `dismissWhenComplete`, because this does not complete — it is what is
|
|
311
|
+
* still in the corner after the checklist has taken itself away.
|
|
312
|
+
*
|
|
313
|
+
* No `trigger`, `frequency` or `priority`, for the three reasons `Checklist`
|
|
314
|
+
* gives. `position` is the launcher's and is shared with the checklist's; where
|
|
315
|
+
* both are published and disagree, the checklist's is drawn.
|
|
316
|
+
*/
|
|
317
|
+
interface ResourceCentre {
|
|
318
|
+
id: string;
|
|
319
|
+
name: string;
|
|
320
|
+
version: number;
|
|
321
|
+
audience?: RuleNode;
|
|
322
|
+
sections: ResourceSection[];
|
|
323
|
+
position?: 'bottom-end' | 'bottom-start';
|
|
324
|
+
}
|
|
189
325
|
interface ThemeTokens {
|
|
190
326
|
accent?: string;
|
|
191
327
|
scrim?: string;
|
|
@@ -203,6 +339,29 @@ interface GuideifyConfig {
|
|
|
203
339
|
envKey: string;
|
|
204
340
|
flows: Flow[];
|
|
205
341
|
settings?: ConfigSettings;
|
|
342
|
+
/**
|
|
343
|
+
* The one persistent surface this environment publishes, if it has one.
|
|
344
|
+
*
|
|
345
|
+
* **Singular, deliberately.** A corner of somebody else's application has
|
|
346
|
+
* room for one launcher; a list invites two of them fighting over the same
|
|
347
|
+
* 56 pixels, and nothing in this product could arbitrate between them.
|
|
348
|
+
*
|
|
349
|
+
* Additive with a safe default, which is the header's rule and is what makes
|
|
350
|
+
* it publishable to environments held on an older core by `sdkPin` (R-04): a
|
|
351
|
+
* core built before this field existed parses the artifact, ignores the key
|
|
352
|
+
* and runs its flows. `packages/sdk/test/checklist-config.test.mjs` pins
|
|
353
|
+
* that, because it is an accident of `validateConfig` until something asserts
|
|
354
|
+
* it.
|
|
355
|
+
*/
|
|
356
|
+
checklist?: Checklist;
|
|
357
|
+
/**
|
|
358
|
+
* The help surface behind the same launcher, if the environment has one.
|
|
359
|
+
*
|
|
360
|
+
* Additive on `checklist`'s argument, and pinned the same way:
|
|
361
|
+
* `packages/sdk/test/resources-config.test.mjs` asserts that a core which has
|
|
362
|
+
* never heard of the key ignores it and runs its flows.
|
|
363
|
+
*/
|
|
364
|
+
resources?: ResourceCentre;
|
|
206
365
|
}
|
|
207
366
|
interface UserTraits {
|
|
208
367
|
[key: string]: unknown;
|