@guideify/react 0.3.0 → 0.5.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 CHANGED
@@ -184,8 +184,41 @@ 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
+ };
189
222
  /**
190
223
  * What marks a checklist item done.
191
224
  *
@@ -236,6 +269,59 @@ interface Checklist {
236
269
  /** Hidden once every item is done, which is the default a customer expects. */
237
270
  dismissWhenComplete?: boolean;
238
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
+ }
239
325
  interface ThemeTokens {
240
326
  accent?: string;
241
327
  scrim?: string;
@@ -268,6 +354,14 @@ interface GuideifyConfig {
268
354
  * it.
269
355
  */
270
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;
271
365
  }
272
366
  interface UserTraits {
273
367
  [key: string]: unknown;
package/dist/index.d.ts CHANGED
@@ -184,8 +184,41 @@ 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
+ };
189
222
  /**
190
223
  * What marks a checklist item done.
191
224
  *
@@ -236,6 +269,59 @@ interface Checklist {
236
269
  /** Hidden once every item is done, which is the default a customer expects. */
237
270
  dismissWhenComplete?: boolean;
238
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
+ }
239
325
  interface ThemeTokens {
240
326
  accent?: string;
241
327
  scrim?: string;
@@ -268,6 +354,14 @@ interface GuideifyConfig {
268
354
  * it.
269
355
  */
270
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;
271
365
  }
272
366
  interface UserTraits {
273
367
  [key: string]: unknown;
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "@guideify/react",
3
- "version": "0.3.0",
3
+ "version": "0.5.0",
4
4
  "license": "SEE LICENSE IN LICENSE",
5
5
  "type": "module",
6
6
  "main": "./dist/index.cjs",