@visitwonders/assembly 0.10.0 → 0.10.1

package/README.md

@@ -13,6 +13,89 @@
 ember install @visitwonders/assembly
 ```
 
+## Setup
+
+Overlay components (`Popover`, `Tooltip`, `Modal`, `Drawer`, `Blanket`,
+`Toast`) render through `ember-primitives`' `<Portal>`. The consuming
+app must mount `<PortalTargets />` once — typically in the application
+template — so that Assembly overlays can find their portal
+destinations:
+
+```gts
+import { PortalTargets } from '@visitwonders/assembly/overlay';
+
+<template>
+  {{outlet}}
+  <PortalTargets />
+</template>
+```
+
+`<PortalTargets />` renders three empty `<div>` elements as portal
+destinations. Its position in the template is layout-neutral —
+overlays use fixed/absolute positioning and don't affect document
+flow.
+
+Without this, the first overlay you open will throw an assertion:
+`Could not find element by the given name: ember-primitives__portal-targets__popover`.
+
+### Integration tests
+
+`setupRenderingTest` does not render the application template, so
+rendering tests that exercise any component containing an overlay
+(directly or transitively — e.g. `SelectField`, `DatePickerField`,
+`MultiSelect`, anything that uses a dropdown or a tooltip-on-label)
+need portal destinations inside `#ember-testing`. The cleanest
+pattern is to inject them in your shared `setupRenderingTest`
+wrapper so every rendering test gets them automatically — no
+per-test boilerplate, no wrapper around `render`:
+
+```ts
+// tests/helpers/index.ts
+import { setupRenderingTest as upstreamSetupRenderingTest } from 'ember-qunit';
+import type { SetupTestOptions } from 'ember-qunit';
+
+const PORTAL_TARGET_NAMES = [
+  'ember-primitives__portal-targets__popover',
+  'ember-primitives__portal-targets__tooltip',
+  'ember-primitives__portal-targets__modal',
+] as const;
+
+export function setupRenderingTest(
+  hooks: NestedHooks,
+  options?: SetupTestOptions,
+) {
+  upstreamSetupRenderingTest(hooks, options);
+
+  hooks.beforeEach(function () {
+    const root = document.getElementById('ember-testing');
+    if (!root) return;
+    for (const name of PORTAL_TARGET_NAMES) {
+      const target = document.createElement('div');
+      target.setAttribute('data-portal-name', name);
+      target.setAttribute('data-test-portal-target', '');
+      root.appendChild(target);
+    }
+  });
+
+  hooks.afterEach(function () {
+    const root = document.getElementById('ember-testing');
+    if (!root) return;
+    for (const target of root.querySelectorAll('[data-test-portal-target]')) {
+      target.remove();
+    }
+  });
+}
+```
+
+This works because `@ember/test-helpers`' `setupRenderingContext`
+appends (rather than replaces) the Ember outlet view inside
+`#ember-testing`, so sibling elements injected here survive every
+`render()` call and are still reachable by `Portal`'s
+`findNearestTarget` walk. Tests can keep importing `render` from
+`@ember/test-helpers` unchanged. Application tests
+(`setupApplicationTest`) are unaffected — they pick up
+`<PortalTargets />` from the application template automatically.
+
 ## Usage
 
 [Longer description of how to use the addon in apps.]

package/dist/layout/panel.css

@@ -227,3 +227,13 @@
 .panel_efcbf2ade[data-variant="filled"][data-tone="neutral"] > .panel-footer_efcbf2ade {
   border-top-color: rgba(0, 0, 0, 0.1);
 }
+
+/* Strip separators at the structural edge — a header-only or
+   footer-only Panel has nothing to separate. */
+.panel_efcbf2ade > .panel-header_efcbf2ade:last-child {
+  border-bottom: none;
+}
+
+.panel_efcbf2ade > .panel-footer_efcbf2ade:first-child {
+  border-top: none;
+}

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@visitwonders/assembly",
-  "version": "0.10.0",
+  "version": "0.10.1",
   "description": "The default blueprint for Embroider v2 addons.",
   "keywords": [
     "ember-addon"