ngwr 11.1.0 → 11.2.0

package/types/ngwr-decrypt-text-testing.d.ts

@@ -0,0 +1,222 @@
+import { BaseHarnessFilters, ComponentHarness, HarnessPredicate } from '@angular/cdk/testing';
+
+/**
+ * @license
+ *
+ * Use of this source code is governed by an MIT-style license that can be
+ * found in the LICENSE file at https://github.com/thekhegay/ngwr/blob/main/LICENSE
+ */
+
+/** Narrows which `<wr-decrypt-text>` a harness query matches. */
+interface WrDecryptTextHarnessFilters extends BaseHarnessFilters {
+    /**
+     * Match the string the component ANNOUNCES — the readable copy, never the scramble.
+     * A string is an exact match, a RegExp is tested.
+     *
+     * This is the only stable thing to address one of these by: the visible layer is a
+     * fresh random draw on every tick, so a filter written against it would match a
+     * different element each time it ran, or none at all.
+     */
+    readonly text?: string | RegExp;
+    /**
+     * Match only settled (`true`) or only scrambled (`false`) instances — the way to pick
+     * out the one that has not been revealed yet on a page holding several.
+     *
+     * Read from the encrypted characters rather than from the glyphs, so it needs no
+     * `Math.random` stub. An instance that rendered no characters at all matches NEITHER
+     * value: "nothing is encrypted" is true of nothing, and a query is the last place that
+     * vacuity should quietly hand back a match.
+     */
+    readonly revealed?: boolean;
+}
+
+/**
+ * @license
+ *
+ * Use of this source code is governed by an MIT-style license that can be
+ * found in the LICENSE file at https://github.com/thekhegay/ngwr/blob/main/LICENSE
+ */
+
+/**
+ * Test harness for `<wr-decrypt-text>`.
+ *
+ * **Two layers, two questions, and they are meant to disagree.** The component renders
+ * the real string once in a visually-hidden span and the scramble in a parallel
+ * `aria-hidden` layer, so {@link getAccessibleText} is what a screen reader hears and
+ * {@link getRenderedText} is what a sighted reader sees. Mid-reveal the second is
+ * literal gibberish while the first must be untouched — that is the contract, and it is
+ * the half nobody looks at. A spec asserting only the visible glyphs would pass on a
+ * component that announced `XQ#PZ`.
+ *
+ * **Prefer the class over the glyphs.** {@link getRevealedIndices},
+ * {@link getEncryptedCount} and {@link isFullyRevealed} read
+ * `.wr-decrypt-text__char--encrypted`, which is deterministic with no stubbing at all —
+ * they are what tell `revealDirection` `'start'` from `'end'` from `'center'`, one index
+ * per tick. {@link getRenderedText} reads the glyphs themselves, which are a fresh
+ * `Math.random()` draw per tick, so stub it (`vi.spyOn(Math, 'random')
+ * .mockReturnValue(0)`) before asserting a string.
+ *
+ * **The clock is the spec's, not the harness's.** The reveal is a `setInterval` this
+ * class does not own, so there is no `advance(ms)` and no `waitUntilRevealed()`: one
+ * would flake on a loaded machine and the other would silently require fake timers to
+ * have been installed. Fake `setInterval` / `clearInterval` and nothing else — faking
+ * the microtask queue freezes the stabilization every `await harness.*()` runs through —
+ * then advance the clock yourself between reads.
+ *
+ * **There is no keyboard path, and this harness does not pretend there is one.**
+ * {@link hover}, {@link mouseAway} and {@link click} are the component's only triggers;
+ * with `animateOn="click"` the host takes a click handler while carrying no role, no
+ * `tabindex` and no keydown handler, so a `focus()` / `sendKeys(Enter)` affordance here
+ * would make a spec pass while a keyboard or switch user could not reveal the text at
+ * all. There is no `enterViewport()` either: `'view'` and `'inViewHover'` hang off an
+ * `IntersectionObserver` jsdom does not implement, so the spec stubs the global and
+ * fires it.
+ *
+ * **Also deliberately absent:** `isAnimating()` — the component has such a signal and it
+ * never reaches the DOM, and deriving it from "something is encrypted" would be wrong in
+ * exactly the interesting case, since `animateOn="click"` rests fully encrypted and
+ * perfectly still. `getSpeed()` / `getMaxIterations()` / `getRevealDirection()` /
+ * `getClickMode()` / `getAnimateOn()` — inputs that are never reflected anywhere, so
+ * reporting them would mean reading the component instance rather than the rendered
+ * control; they are observable as behaviour, which is what the methods above measure.
+ * `getScrambleAlphabet()` — the pool is internal and each frame shows one random draw
+ * from it, so any reconstruction is a guess that gets worse the shorter the string.
+ * `getCharColors()` / `isDimmed()` — the `--encrypted` rule is deliberately EMPTY, a
+ * styling hook for consumers, so there is nothing painted to read in any environment.
+ *
+ * @example
+ * ```ts
+ * const secret = await loader.getHarness(WrDecryptTextHarness.with({ text: 'Hello' }));
+ *
+ * await secret.hover();
+ * vi.advanceTimersByTime(50);
+ *
+ * expect(await secret.getRevealedIndices()).toEqual([0]);   // sequential, from the start
+ * expect(await secret.getAccessibleText()).toBe('Hello');   // untouched throughout
+ * ```
+ *
+ * @see https://ngwr.dev/guides/testing
+ */
+declare class WrDecryptTextHarness extends ComponentHarness {
+    static hostSelector: string;
+    /** Build a predicate that narrows the query — pass to `getHarness` / `getAllHarnesses`. */
+    static with(options?: WrDecryptTextHarnessFilters): HarnessPredicate<WrDecryptTextHarness>;
+    private readonly chars;
+    private readonly encrypted;
+    /**
+     * The real string, as the one readable copy holds it.
+     *
+     * The single highest-value assertion here: it must stay equal to the `text` input on
+     * every frame, while the visible layer is unreadable by design. Lose this span and the
+     * component announces nothing at all — every drawn character sits under `aria-hidden`,
+     * so no other part of the DOM would change.
+     *
+     * Untrimmed, so that it can be compared against {@link getRenderedText} without one
+     * side of the comparison quietly forgiving a lost leading space.
+     */
+    getAccessibleText(): Promise<string>;
+    /**
+     * What is on screen this frame — scramble glyphs and all, in document order.
+     *
+     * Plain before anything triggers it, gibberish mid-reveal, and the real string once it
+     * settles; comparing it against {@link getAccessibleText} is how a spec says which of
+     * those it is looking at. `useOriginalCharsOnly` is visible only here — every glyph
+     * has to be one the text really contains.
+     *
+     * Nondeterministic unless the spec stubs `Math.random`, because each unrevealed
+     * position is an independent draw from the pool. When the assertion does not actually
+     * need the glyphs, {@link getRevealedIndices} answers the same progress question off
+     * the class and needs no stub.
+     */
+    getRenderedText(): Promise<string>;
+    /**
+     * How many characters the animation walks.
+     *
+     * CODE POINTS, not UTF-16 units: `'a🚀b'` is 3 here, and the indices
+     * {@link getRevealedIndices} returns line up with `[...text]` rather than with plain
+     * `text[i]`. That distinction is not pedantry — counting units gave a sequential
+     * reveal extra ticks with no character to spend them on, and made "everything is
+     * revealed" disagree with what was on screen.
+     */
+    getCharCount(): Promise<number>;
+    /**
+     * The positions that have settled on their real character, ascending.
+     *
+     * The payload method, and the deterministic one: it reads the `--encrypted` modifier
+     * rather than the glyphs, so no `Math.random` stub is involved. It is the only thing
+     * that separates `revealDirection` `'start'` (`[0]`, `[0, 1]`, …) from `'end'`
+     * (`[4]`, `[3, 4]`, …) from `'center'` (`[2]`, `[1, 2]`, …), and one index per tick is
+     * what makes a sequential reveal sequential.
+     *
+     * Ascending by position, NOT in the order the reveal visited them — the DOM records
+     * which characters have landed, never the path taken to them. Assert the set after
+     * each tick to pin an order.
+     */
+    getRevealedIndices(): Promise<number[]>;
+    /**
+     * How many characters are still scrambled.
+     *
+     * The coarse progress read, and the cheapest way to say "scrambled on hover", "plain on
+     * leave", or "a reader who asked for less motion never saw a scramble at all". Class-
+     * based like {@link getRevealedIndices}, so it too is random-proof.
+     */
+    getEncryptedCount(): Promise<number>;
+    /**
+     * Whether every character has settled.
+     *
+     * Deliberately does NOT also compare {@link getRenderedText} against
+     * {@link getAccessibleText}: folding two conditions into one boolean hides which of
+     * them broke, and a spec that wants both should write both lines.
+     *
+     * Throws when nothing was rendered. "No character is encrypted" is true of no
+     * characters, which is the same answer a component that stopped rendering its text
+     * would give — and this is the method most likely to be the only assertion in a test.
+     */
+    isFullyRevealed(): Promise<boolean>;
+    /**
+     * Whether the scramble layer is out of the accessibility tree.
+     *
+     * The contract that keeps a screen reader from spelling out `XQ#PZ` beside the real
+     * string it already read. Worth a method rather than an assumption because the wrapper
+     * holding the characters carries NO class — it can only be addressed as the readable
+     * span's next sibling, which any template reshuffle breaks.
+     *
+     * Throws when that structural selector finds nothing, rather than returning `false`: a
+     * missing wrapper and an unhidden one are different failures, and the answer to
+     * "is the scramble hidden" when there is no scramble layer at all is not `false`.
+     */
+    isAnimatedLayerHidden(): Promise<boolean>;
+    /**
+     * Point at it — the trigger for `animateOn` `'hover'` and `'inViewHover'`.
+     *
+     * Drives the component the way a user does, and works in a test because the trigger is
+     * an event rather than a gesture: `TestElement.hover()` dispatches `pointerenter`,
+     * `mouseover` and `mouseenter`, and the component listens for the last of those. A
+     * hand-rolled pointer-only dispatch would not reach it.
+     *
+     * Does nothing in the other two modes, exactly as a real pointer does nothing there.
+     */
+    hover(): Promise<void>;
+    /**
+     * Move the pointer off — the other half of hover mode.
+     *
+     * Pins the promise that leaving mid-scramble restores the real text IMMEDIATELY rather
+     * than letting the reveal play out: the reader took the effect away, so the string has
+     * to come back at once.
+     */
+    mouseAway(): Promise<void>;
+    /**
+     * Click the host — the `animateOn="click"` trigger, and the only way to tell
+     * `clickMode` `'once'` from `'toggle'`.
+     *
+     * There is no keyboard equivalent, and that is a statement about the component rather
+     * than about this harness: in click mode the host carries a click handler with no role,
+     * no `tabindex` and no keydown handler, so a keyboard or switch user cannot reveal the
+     * text at all. A `sendKeys(Enter)` here would invent an affordance that does not exist
+     * and let a spec pass over the top of it.
+     */
+    click(): Promise<void>;
+}
+
+export { WrDecryptTextHarness };
+export type { WrDecryptTextHarnessFilters };

package/types/ngwr-donut-chart-testing.d.ts

@@ -0,0 +1,79 @@
+import { BaseHarnessFilters, ComponentHarness, HarnessPredicate } from '@angular/cdk/testing';
+
+/**
+ * @license
+ *
+ * Use of this source code is governed by an MIT-style license that can be
+ * found in the LICENSE file at https://github.com/thekhegay/ngwr/blob/main/LICENSE
+ */
+
+/** Narrows which `<wr-donut-chart>` a harness query matches. */
+interface WrDonutChartHarnessFilters extends BaseHarnessFilters {
+    /** Match the chart's accessible name. */
+    readonly ariaLabel?: string | RegExp;
+    /** Match a chart whose legend holds this label. */
+    readonly sliceLabel?: string | RegExp;
+}
+/** One legend row — the only place a slice's label and value are readable. */
+interface WrDonutChartLegendEntry {
+    readonly label: string;
+    readonly value: string;
+}
+
+/**
+ * @license
+ *
+ * Use of this source code is governed by an MIT-style license that can be
+ * found in the LICENSE file at https://github.com/thekhegay/ngwr/blob/main/LICENSE
+ */
+
+/**
+ * Test harness for `<wr-donut-chart>`.
+ *
+ * **The ring itself is unreadable, and that is by design.** The slices are SVG
+ * paths inside an `aria-hidden` drawing: a screen reader is given the chart's
+ * `aria-label` and nothing else, and a spec cannot get a label or a value off a
+ * path's `d`. {@link getLegend} is where the numbers are — which is also the
+ * argument for keeping `showLegend` on, since with it off the chart's data has no
+ * textual form at all.
+ *
+ * {@link getSliceCount} is therefore the one thing the ring answers: how many
+ * wedges were drawn. Compare it with the legend's length to catch a slice that was
+ * filtered out of one and not the other.
+ *
+ * @example
+ * ```ts
+ * const chart = await loader.getHarness(WrDonutChartHarness);
+ *
+ * expect(await chart.getSliceCount()).toBe(3);
+ * expect(await chart.getLegend()).toEqual([
+ *   { label: 'Direct', value: '48' },
+ *   { label: 'Search', value: '32' },
+ *   { label: 'Social', value: '20' },
+ * ]);
+ * ```
+ *
+ * @see https://ngwr.dev/guides/testing
+ */
+declare class WrDonutChartHarness extends ComponentHarness {
+    static hostSelector: string;
+    /** Build a predicate that narrows the query — pass to `getHarness` / `getAllHarnesses`. */
+    static with(options?: WrDonutChartHarnessFilters): HarnessPredicate<WrDonutChartHarness>;
+    /** The name the ring announces — the whole chart's, since the slices announce nothing. */
+    getAccessibleName(): Promise<string | null>;
+    /** How many wedges were drawn. */
+    getSliceCount(): Promise<number>;
+    /** Whether the legend is rendered (`showLegend`, and at least one slice). */
+    hasLegend(): Promise<boolean>;
+    /** The legend rows in order — the only textual form the data has. */
+    getLegend(): Promise<WrDonutChartLegendEntry[]>;
+    /** The big number in the middle, or `null` when the chart has none. */
+    getCenterValue(): Promise<string | null>;
+    /** The caption under the centre value, or `null`. */
+    getCenterLabel(): Promise<string | null>;
+    /** The ring's diameter in pixels, as the component writes it inline. */
+    getSize(): Promise<number>;
+}
+
+export { WrDonutChartHarness };
+export type { WrDonutChartHarnessFilters, WrDonutChartLegendEntry };

package/types/ngwr-drawer.d.ts

@@ -143,6 +143,18 @@ declare class WrDrawer {
     private focusTrap;
     private previouslyFocused;
     constructor();
+    /**
+     * Point the panel's `aria-labelledby` at the CURRENT `[wrDrawerTitle]`.
+     *
+     * Re-resolved after every render rather than once when the drawer opens,
+     * because the title element is projected content and can come and go while
+     * the drawer stays open — an `@if` around it, or a heading that only exists
+     * once the data arrives. A one-shot lookup leaves the attribute naming an
+     * element that has been removed or replaced, and a dangling reference is not
+     * a name: the dialog is announced as unnamed, with nothing on screen to say
+     * so. A missing title clears the attribute for the same reason.
+     */
+    private syncLabel;
     private openOverlay;
     private closeOverlay;
     static ɵfac: _angular_core.ɵɵFactoryDeclaration<WrDrawer, never>;

package/types/ngwr-dropdown.d.ts

@@ -97,6 +97,15 @@ declare class WrDropdown {
     /** Toggle the menu. */
     toggle(): void;
     /** @internal */
+    /**
+     * Whether the pointer, rather than the keyboard, opened the current menu.
+     *
+     * A hover-opened menu must not take focus — the APG shows a menu on hover and
+     * leaves the caret where it was — while a keyboard-opened one must. The
+     * trigger MODE cannot answer that on its own: a `trigger="hover"` menu is
+     * still openable with Enter, and that open should focus the first item.
+     */
+    private openedByPointer;
     protected onClick(event: MouseEvent): void;
     /** @internal */
     protected onMouseEnter(): void;

package/types/ngwr-event-calendar-testing.d.ts

@@ -0,0 +1,301 @@
+import { BaseHarnessFilters, ComponentHarness, HarnessPredicate } from '@angular/cdk/testing';
+import { WrCalendarView } from 'ngwr/event-calendar';
+
+/**
+ * @license
+ *
+ * Use of this source code is governed by an MIT-style license that can be
+ * found in the LICENSE file at https://github.com/thekhegay/ngwr/blob/main/LICENSE
+ */
+
+/** Narrows which `<wr-event-calendar>` a harness query matches. */
+interface WrEventCalendarHarnessFilters extends BaseHarnessFilters {
+    /** Match the header title as printed — a string is an exact match, a RegExp is tested. */
+    readonly title?: string | RegExp;
+    /** Match the view the calendar is showing. */
+    readonly view?: WrCalendarView;
+}
+/** Narrows which event chip a harness query matches. */
+interface WrEventCalendarChipHarnessFilters extends BaseHarnessFilters {
+    /**
+     * Match the chip's accessible name, which is the time and the title together —
+     * the visible text is `aria-hidden`, so this is what a screen reader gets.
+     */
+    readonly label?: string | RegExp;
+    /** Match the chip's title text as printed. */
+    readonly title?: string | RegExp;
+    /** Match day-spanning bands (`true`) or timed chips (`false`). */
+    readonly band?: boolean;
+}
+
+/**
+ * @license
+ *
+ * Use of this source code is governed by an MIT-style license that can be
+ * found in the LICENSE file at https://github.com/thekhegay/ngwr/blob/main/LICENSE
+ */
+
+/** The arrow keys, by the direction a user would say out loud. */
+type Arrow$1 = 'left' | 'right' | 'up' | 'down';
+/**
+ * Test harness for one event chip inside a {@link WrEventCalendarHarness}.
+ *
+ * **The visible text is `aria-hidden`; the name is on the button.** A chip prints a
+ * time and a title for the eye, and publishes both as one `aria-label` for a screen
+ * reader — so {@link getLabel} is what the control announces and {@link getTitle} is
+ * what is drawn. They are separate because a consumer's `[wrCalendarEvent]` template
+ * replaces the drawn half and not the announced one.
+ *
+ * **Moving and resizing are on the keyboard here, and not because of jsdom.** The
+ * pointer drag is real, but the same two operations are bound to the arrows —
+ * `Alt` to move, `Alt` + `Shift` to resize — precisely so the calendar is usable
+ * without one. That is the path this harness drives; a synthetic drag would divide
+ * by a rect that measures 0×0 anyway.
+ *
+ * @see https://ngwr.dev/guides/testing
+ */
+declare class WrEventCalendarChipHarness extends ComponentHarness {
+    static hostSelector: string;
+    /** Build a predicate that narrows the query — pass to `getHarness` / `getAllHarnesses`. */
+    static with(options?: WrEventCalendarChipHarnessFilters): HarnessPredicate<WrEventCalendarChipHarness>;
+    /** What the chip announces — its time and title in one string. */
+    getLabel(): Promise<string | null>;
+    /**
+     * The title as drawn, or `null` when a consumer template replaced it.
+     *
+     * The default chip prints its own `.wr-event-calendar__chip-title`; a
+     * `[wrCalendarEvent]` template renders whatever the consumer wrote instead, and
+     * there is no title element to find. {@link getText} is the fallback that always
+     * answers.
+     */
+    getTitle(): Promise<string | null>;
+    /** The chip's whole rendered text, whoever drew it. */
+    getText(): Promise<string>;
+    /** The time as printed on a timed chip, or `null` on a band, which prints none. */
+    getTime(): Promise<string | null>;
+    /**
+     * Whether this is a day-spanning BAND rather than a timed chip.
+     *
+     * One shape covers two places — a month cell and the all-day row — and the other
+     * is the block in a time grid. They size themselves completely differently (a
+     * `calc()` width across columns versus a percentage height down one), which is why
+     * the two are worth telling apart.
+     */
+    isBand(): Promise<boolean>;
+    /** Whether the event started before this cell — the chip is drawn cut off at the leading edge. */
+    continuesBefore(): Promise<boolean>;
+    /** Whether the event runs past this cell. */
+    continuesAfter(): Promise<boolean>;
+    /** Whether the chip is mid-drag. */
+    isDragging(): Promise<boolean>;
+    /**
+     * Whether the chip offers a resize grab area.
+     *
+     * It is `aria-hidden` and not focusable on purpose — the same resize is `Alt` +
+     * `Shift` + arrows on the chip itself, so a second tab stop here would lead
+     * nowhere. Its
+     * presence is still the mouse affordance, and it is dropped on a chip whose event
+     * continues past this cell.
+     */
+    hasResizeHandle(): Promise<boolean>;
+    /**
+     * Click the chip — which emits `eventClick` and does NOT bubble to the cell
+     * underneath.
+     *
+     * On an editable calendar this needs `document.elementFromPoint` to exist: the CDK
+     * dispatches a whole pointer sequence, and the chip's `pointerdown` hit-tests for
+     * the cell under the cursor. jsdom implements no such method, so stub it in your
+     * spec — `() => null` is the honest answer where nothing has a box — or the click
+     * throws out of the listener.
+     */
+    click(): Promise<void>;
+    /** Move keyboard focus to the chip. */
+    focus(): Promise<void>;
+    /** Whether the chip currently holds focus. */
+    isFocused(): Promise<boolean>;
+    /**
+     * Move the event — `Alt` + an arrow, a day sideways or a slot vertically.
+     *
+     * The calendar never mutates `events`: this emits `eventChange` and the host is
+     * expected to apply it. A spec whose host ignores the output is asserting a
+     * CANCELLED move, which is the contract and the most common surprise here. A
+     * calendar without `editable` ignores the keys entirely — the same gate the pointer
+     * path uses.
+     */
+    move(arrow: Arrow$1): Promise<void>;
+    /**
+     * Resize the event — `Alt` + `Shift` + an arrow, which moves the END alone.
+     *
+     * A resize that would end at or before the start emits nothing rather than
+     * inverting the event, which is the pointer path's rule too.
+     */
+    resize(arrow: Arrow$1): Promise<void>;
+    /** Press a bare arrow — which the chip ignores, letting the grid's own navigation run. */
+    pressArrow(arrow: Arrow$1): Promise<void>;
+    /** Press Escape — handing focus back to the cell the chip sits in. */
+    sendEscape(): Promise<void>;
+}
+
+/**
+ * @license
+ *
+ * Use of this source code is governed by an MIT-style license that can be
+ * found in the LICENSE file at https://github.com/thekhegay/ngwr/blob/main/LICENSE
+ */
+
+/** The arrow keys, by the direction a user would say out loud. */
+type Arrow = 'left' | 'right' | 'up' | 'down';
+/**
+ * Test harness for `<wr-event-calendar>` — month, week and day in one component.
+ *
+ * **Every chip lives inside the `role="gridcell"` where its event STARTS**, and
+ * reaches out from there with a `calc()` width or a percentage height. That is a
+ * deliberate structural choice — a floating events layer would leave `role="row"`
+ * owning something other than cells — and it is why {@link getChips} can be scoped
+ * to a cell at all.
+ *
+ * **The view is read from the DOM, not from the input.** A month renders one grid
+ * shape and week / day another, and those two are told apart by how many day columns
+ * they draw. That is the honest answer for a harness: `view` is a model a consumer
+ * can write, and the grid is what the user sees.
+ *
+ * **Nothing here mutates the events.** A move or a resize emits `eventChange` and
+ * the host applies it — so a spec whose host ignores the output is asserting a
+ * CANCELLED gesture, which is the contract rather than a bug.
+ *
+ * @example
+ * ```ts
+ * const calendar = await loader.getHarness(WrEventCalendarHarness);
+ *
+ * expect(await calendar.getView()).toBe('month');
+ * const [standup] = await calendar.getChips({ title: 'Standup' });
+ * await standup.move('right');
+ * ```
+ *
+ * @see https://ngwr.dev/guides/testing
+ */
+declare class WrEventCalendarHarness extends ComponentHarness {
+    static hostSelector: string;
+    /** Build a predicate that narrows the query — pass to `getHarness` / `getAllHarnesses`. */
+    static with(options?: WrEventCalendarHarnessFilters): HarnessPredicate<WrEventCalendarHarness>;
+    private readonly grid;
+    /**
+     * Which view is on screen.
+     *
+     * `month` has its own grid modifier; `week` and `day` share the time grid and are
+     * told apart by the column count the component publishes on it. Reading the DOM
+     * rather than the `view` model is the point — that model is an input a consumer can
+     * set to anything, and this is what got rendered.
+     */
+    getView(): Promise<WrCalendarView>;
+    /** The header title — the month, the week's range, or the day. */
+    getTitle(): Promise<string>;
+    /** Whether the header is rendered at all (`hideHeader`). */
+    hasHeader(): Promise<boolean>;
+    /** The grid's accessible name. */
+    getAccessibleName(): Promise<string | null>;
+    /** Step back one month, week or day, depending on the view. */
+    previous(): Promise<void>;
+    /** Step forward one month, week or day. */
+    next(): Promise<void>;
+    /** Press the Today button — jumping to the period containing today. */
+    goToday(): Promise<void>;
+    /** The back arrow's accessible name — the two steps are icon-only. */
+    getPreviousLabel(): Promise<string | null>;
+    /** The forward arrow's accessible name. */
+    getNextLabel(): Promise<string | null>;
+    /** The Today button's label. */
+    getTodayLabel(): Promise<string>;
+    /**
+     * The view switcher's labels, in order — empty when the calendar was given a single
+     * view, which drops the switcher entirely.
+     */
+    getViewLabels(): Promise<string[]>;
+    /** The label of the view currently pressed, or `null` when there is no switcher. */
+    getActiveViewLabel(): Promise<string | null>;
+    /**
+     * Switch view by the label the switcher prints.
+     *
+     * By label rather than by the `WrCalendarView` value, because the label is what the
+     * DOM has — the value never reaches it, and a spec that passed one would be naming
+     * something only the component can see. {@link getViewLabels} lists them.
+     */
+    setView(label: string): Promise<void>;
+    /** The weekday column headers of the month view. */
+    getWeekdayNames(): Promise<string[]>;
+    /** The day numbers of the month grid, in order — 42 of them, spill days included. */
+    getDayNumbers(): Promise<string[]>;
+    /** The time-gutter labels down the left of a week or day view. */
+    getSlotLabels(): Promise<string[]>;
+    /** Whether the time views drew an all-day band, which they only do when something needs it. */
+    hasAllDayRow(): Promise<boolean>;
+    /**
+     * Every chip on screen, in DOM order.
+     *
+     * A multi-day event has ONE chip, in the cell where it starts — the band reaches
+     * across the rest — so this counts events-in-view rather than event-days.
+     */
+    getChips(filters?: WrEventCalendarChipHarnessFilters): Promise<WrEventCalendarChipHarness[]>;
+    /** The chips' announced names, in DOM order. */
+    getChipLabels(): Promise<(string | null)[]>;
+    /**
+     * The "+N more" overflow buttons of the month view, by the text they print.
+     *
+     * A month cell shows `maxLanes` chips and hides the rest behind one of these, which
+     * opens the day view — so its presence is the only sign that a cell has more than
+     * it is showing.
+     */
+    getOverflowLabels(): Promise<string[]>;
+    /** Click the first "+N more" button, which drops to the day view for that date. */
+    openOverflow(): Promise<void>;
+    /**
+     * Click an empty part of a cell — which emits `slotClick` with its date and minutes.
+     *
+     * A cell is addressed by its DAY and, in a time view, the minutes from midnight of
+     * its row (`-1` means a month cell or the all-day band). Both come off the two data
+     * attributes every cell publishes for the drag's own hit-testing, which makes them
+     * the one stable way to name a cell from outside — a row index would mean something
+     * different in each view.
+     */
+    clickCell(day: Date, minutes?: number): Promise<void>;
+    /** A cell's accessible name — the date, and the time for a slot. */
+    getCellLabel(day: Date, minutes?: number): Promise<string | null>;
+    /** The chips inside ONE cell, which is where a chip's event starts. */
+    getCellChips(day: Date, minutes?: number): Promise<WrEventCalendarChipHarness[]>;
+    /**
+     * The grid's single tab stop, as `"<day>:<minutes>"`.
+     *
+     * The cursor roves rather than every cell being tabbable, and it is RAW — it
+     * survives a view switch, so the same pair means a different cell in a month grid
+     * and a week one.
+     */
+    getCursor(): Promise<string | null>;
+    /** Move keyboard focus to a cell, which is also what moves the roving cursor onto it. */
+    focusCell(day: Date, minutes?: number): Promise<void>;
+    /**
+     * Press an arrow on the cell that currently holds the cursor.
+     *
+     * Sent to that cell rather than to the grid, because the component listens per cell
+     * — the element carrying the keyboard should be the one that holds focus — and
+     * anything originating inside a chip is deliberately let through untouched.
+     */
+    pressArrow(arrow: Arrow): Promise<void>;
+    /** Press Home on the cursor cell — the first day of its week. */
+    pressHome(): Promise<void>;
+    /** Press End on the cursor cell — the last day of its week. */
+    pressEnd(): Promise<void>;
+    private step;
+    private stepElement;
+    private headerButton;
+    /**
+     * The stamp a cell publishes for a day — local midnight, which is what the
+     * component's own `startOfDay` produces. Taking a `Date` and normalising here keeps
+     * the timestamp out of every spec.
+     */
+    private stamp;
+    private requireCell;
+    private cursorCell;
+}
+
+export { WrEventCalendarChipHarness, WrEventCalendarHarness };
+export type { WrEventCalendarChipHarnessFilters, WrEventCalendarHarnessFilters };

package/types/ngwr-event-calendar.d.ts

@@ -220,13 +220,16 @@ declare class WrEventCalendar {
     private readonly document;
     private readonly dir;
     private readonly chipTpl;
-    protected readonly todayLabel: string;
-    protected readonly previousLabel: string;
-    protected readonly nextLabel: string;
-    protected readonly allDayLabel: string;
-    protected readonly timeLabel: string;
+    protected readonly todayLabel: _angular_core.Signal<string>;
+    protected readonly previousLabel: _angular_core.Signal<string>;
+    protected readonly nextLabel: _angular_core.Signal<string>;
+    protected readonly allDayLabel: _angular_core.Signal<string>;
+    protected readonly timeLabel: _angular_core.Signal<string>;
     protected readonly moreLabel: (params?: ngwr_i18n.WrI18nParams) => string;
-    protected readonly viewLabels: Record<WrCalendarView, string>;
+    private readonly monthLabel;
+    private readonly weekLabel;
+    private readonly dayLabel;
+    protected readonly viewLabels: _angular_core.Signal<Record<WrCalendarView, string>>;
     /** Accessible name of the grid; overridable for a page with several. */
     readonly ariaLabel: _angular_core.InputSignal<string | null>;
     protected readonly resolvedAriaLabel: _angular_core.Signal<string>;