@blackbaud/skyux-lib-addin-client 14.1.0 → 15.0.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 CHANGED
@@ -245,7 +245,7 @@ this.addinClientService.addEventHandler({
245
245
  { id: 1, name: 'Item 1' },
246
246
  { id: 2, name: 'Item 2' }
247
247
  ];
248
-
248
+
249
249
  addinEvent.done(data);
250
250
  });
251
251
  ```
@@ -321,41 +321,113 @@ export class MyModule { }
321
321
 
322
322
  For more information on creating SKY Add-ins, view the documentation on the [SKY Developer Portal](https://developer.blackbaud.com/skyapi/docs/addins)
323
323
 
324
- ## Modal style
324
+ ## Hosted add-in backgrounds
325
325
 
326
- Requires version 14.1.0 of this library, which depends on `@blackbaud/sky-addin-client` 1.8.0 or later.
326
+ Starting in version 15.0.0, the add-in client gives the add-in document the SKY UX
327
+ background that matches where the add-in is hosted, in the current theme and mode:
327
328
 
328
- A modal add-in can independently configure its document background and the host's overlay through `modalConfig.style`. This library passes these options to `@blackbaud/sky-addin-client` unchanged and doesn't supply defaults.
329
+ - Modal add-ins get a transparent background, so the SKY UX modal backdrop shows behind
330
+ the modal.
331
+ - Box, Tile, Flyout, and Vertical Tab Form add-ins use the SKY UX container background, as
332
+ SKY UX boxes, tiles, and flyouts do for their own content.
333
+ - Page, Tab, Generic, full-page modal, Button, Action Button, and Dataset add-ins keep their
334
+ own background. SKY UX tabs don't give their content a background, so a Tab add-in
335
+ matches whatever is behind its tabset, usually the page. A Generic add-in is embedded with
336
+ `sky-addin` and no more specific type, typically as part of a page.
337
+ - When the client can't determine where the add-in is hosted, it uses the SKY UX container
338
+ background.
329
339
 
330
- | Option | Behavior |
331
- |---|---|
332
- | `transparentBackground: true` | Makes the add-in document's `html` and `body` backgrounds transparent. |
333
- | `transparentBackground: false` or omitted | Preserves the add-in's document background. |
334
- | `hostOverlay: false` | Asks the host to make its overlay transparent. Hosts that do not support this option ignore it. |
335
- | `hostOverlay: true` or omitted | Preserves the host's visible overlay. |
340
+ The client adds one `<style>` element for these backgrounds. If the add-in's Content
341
+ Security Policy restricts `style-src`, provide the nonce to Angular through `CSP_NONCE` or
342
+ the `ngCspNonce` attribute, as Angular requires for component styles. The client applies
343
+ the same nonce.
344
+
345
+ ### Remove historical style overrides
346
+
347
+ Modal add-ins previously needed global style overrides to make their document transparent
348
+ and hide the SKY UX modal backdrop. Remove them:
349
+
350
+ ```scss
351
+ ::ng-deep body { background: transparent; }
352
+ ::ng-deep .sky-modal-host-backdrop { display: none; }
353
+ ```
354
+
355
+ The client now makes the document transparent itself and keeps the SKY UX modal backdrop
356
+ visible. Until you remove these rules, the client overrides the rule that hides the
357
+ backdrop, so existing add-ins keep working.
358
+
359
+ ### Modal add-ins that don't open a SKY UX modal
360
+
361
+ A modal add-in that renders its content directly, instead of opening a SKY UX modal,
362
+ should keep its own background. Send an empty style in `ready()`:
336
363
 
337
364
  ```ts
338
365
  args.ready({
339
366
  showUI: true,
340
367
  modalConfig: {
341
- style: {
342
- transparentBackground: true,
343
- hostOverlay: false
344
- }
368
+ style: {}
345
369
  }
346
370
  });
347
371
  ```
348
372
 
349
- With both options set on a compatible host, the add-in document is transparent and the host's overlay is transparent, so the SKY UX modal backdrop is the only visible scrim.
373
+ Any `modalConfig.style`, including an empty object, turns off the automatic background for
374
+ that `ready()` call. See [Modal style](#modal-style).
350
375
 
351
- The add-in client applies `transparentBackground` itself, so it works on any host. When you set it, you can remove this historical rule:
376
+ ### Choose the add-in's background
352
377
 
353
- ```scss
354
- ::ng-deep body { background: transparent; }
378
+ To choose the background instead of the automatic one, extend `AddinClientConfigService`
379
+ (see [Additional configuration](#additional-configuration)) and override
380
+ `getHostedSurfaceMode()`. It can return:
381
+
382
+ | Mode | Behavior |
383
+ |---|---|
384
+ | `'automatic'` (default) | Uses the background for where the add-in is hosted, as described above. |
385
+ | `'preserve'` | Keeps the add-in's own background. The client doesn't change the add-in document. |
386
+ | `'container'` | Uses the SKY UX container background, wherever the add-in is hosted. |
387
+
388
+ The client asks on every `ready()` call and passes the add-in type the host reported, if
389
+ any, and the arguments the add-in passed to `ready()`. That lets an add-in that's hosted in
390
+ several places choose for each one, for example by route:
391
+
392
+ ```ts
393
+ class AddinConfigService extends AddinClientConfigService {
394
+ readonly #router = inject(Router);
395
+
396
+ public override getHostedSurfaceMode(
397
+ context: AddinClientHostedSurfaceContext
398
+ ): AddinClientHostedSurfaceMode {
399
+ // The list page renders as part of the host's page, so it keeps the page background.
400
+ return this.#router.url.startsWith('/single-list') ? 'preserve' : 'automatic';
401
+ }
402
+ }
355
403
  ```
356
404
 
357
- `hostOverlay: false` requires a compatible host. Make these two changes together: remove the rule below and set `hostOverlay: false`. On a host that ignores `hostOverlay`, removing the rule shows the SKY UX backdrop on top of the host's overlay (a double scrim). On a compatible host, keeping the rule while setting `hostOverlay: false` leaves no scrim. If your add-in runs on hosts that don't support `hostOverlay`, keep this rule and omit `hostOverlay`:
405
+ A modal add-in can still set `modalConfig.style` explicitly, whatever the mode.
358
406
 
359
- ```scss
360
- ::ng-deep .sky-modal-host-backdrop { display: none; }
407
+ ## Modal style
408
+
409
+ A modal add-in can set its document background and the host's overlay explicitly through
410
+ `modalConfig.style`. The two options are independent:
411
+
412
+ | Option | Behavior |
413
+ |---|---|
414
+ | `transparentBackground: true` | Makes the add-in document transparent with inline `!important` `background-color: transparent` and `background-image: none` declarations on `<html>` and `<body>`. |
415
+ | `transparentBackground: false` or omitted | Keeps the add-in's own background. |
416
+ | `hostOverlay: false` | Asks the host to make its modal overlay transparent. |
417
+ | `hostOverlay: true` or omitted | The host keeps its visible modal overlay. |
418
+
419
+ ```ts
420
+ args.ready({
421
+ showUI: true,
422
+ modalConfig: {
423
+ style: {
424
+ transparentBackground: true,
425
+ hostOverlay: false
426
+ }
427
+ }
428
+ });
361
429
  ```
430
+
431
+ With both options set, the add-in document and the host's overlay are transparent, so the
432
+ SKY UX modal backdrop is the only visible scrim. Defining `modalConfig.style`, including an
433
+ empty object, turns off the automatic background for that `ready()` call.