courthive-components 4.1.2 → 4.2.0

package/dist/components/schedule-page/index.d.ts

@@ -16,6 +16,8 @@ export { buildScheduleDateStrip } from './ui/dateStrip';
 export { buildScheduleIssuesPanel } from './ui/issuesPanel';
 export { buildMatchUpCatalog } from './ui/matchUpCatalog';
 export { buildMatchUpCard } from './ui/matchUpCard';
+export type { CardTimeStatus, MatchUpCardCallbacks, MatchUpCardOptions } from './ui/matchUpCard';
+export { applyRelatedHighlight, clearRelatedHighlight, RELATED_HIGHLIGHT } from './ui/matchUpHighlight';
 export { buildScheduleInspectorPanel } from './ui/inspectorPanel';
 export type { ScheduleInspectorPanelOptions } from './ui/inspectorPanel';
 export { buildCourtGridSlot } from './ui/courtGridSlot';

package/dist/components/schedule-page/types.d.ts

@@ -140,6 +140,12 @@ export interface SchedulePageConfig {
      *  nothing. Consumers that build cards themselves (e.g. a Scheduled panel calling
      *  `buildMatchUpCard` directly) pass the same function as `MatchUpCardOptions.renderExtra`. */
     renderCardExtra?: (matchUp: CatalogMatchUpItem) => HTMLElement | null;
+    /** MatchUps a card is entangled with, resolved when the pointer enters it and
+     *  highlighted wherever the page draws them — grid cells, other cards, strip
+     *  cells. The consumer owns the relation; this component sees one matchUp at a
+     *  time and could not compute "waiting on" if it wanted to. Omit to leave
+     *  cards without hover highlighting. */
+    relatedMatchUpIds?: (matchUp: CatalogMatchUpItem) => string[];
     /** Consumer-owned buttons rendered right-aligned in the court grid header.
      *  Consumer keeps live refs and mutates state (visibility, disabled, label) directly. */
     headerActions?: HTMLElement | HTMLElement[];

package/dist/components/schedule-page/ui/matchUpCard.d.ts

@@ -1,4 +1,11 @@
 import { CatalogMatchUpItem } from '../types';
+/**
+ * Grading for the prominent time header. The consumer owns the rule — the card
+ * knows only that `ok` is achievable, `warn` is achievable-but-compromised and
+ * `alert` is not achievable at all. Omitted leaves the header at its default
+ * (green) styling, which is what every consumer got before this option existed.
+ */
+export type CardTimeStatus = 'ok' | 'warn' | 'alert';
 export interface MatchUpCardCallbacks {
     onClick?: (matchUp: CatalogMatchUpItem) => void;
 }
@@ -20,5 +27,17 @@ export interface MatchUpCardOptions {
      *  its default styling (used for non-catalog renders + scheduled / completed
      *  cards where round priority is meaningless). */
     roundOffset?: number;
+    /** Grading for the `prominentTime` header — see `CardTimeStatus`. Ignored when
+     *  the header is not rendered. */
+    timeStatus?: CardTimeStatus;
+    /** Hover text for the time header, explaining what the grading is reading.
+     *  A colour that cannot be interrogated is a colour the operator learns to
+     *  distrust, so a graded header should always carry one. */
+    timeTitle?: string;
+    /** MatchUps this card depends on, resolved on hover and highlighted wherever
+     *  they are drawn — see `matchUpHighlight.ts`. The consumer owns the relation;
+     *  this component sees one matchUp and could not compute "waiting on". Omit to
+     *  leave the card without hover highlighting. */
+    relatedMatchUpIds?: (item: CatalogMatchUpItem) => string[];
 }
 export declare function buildMatchUpCard(item: CatalogMatchUpItem, callbacks: MatchUpCardCallbacks, options?: MatchUpCardOptions): HTMLElement;

package/dist/components/schedule-page/ui/matchUpCatalog.d.ts

@@ -9,5 +9,7 @@ export interface MatchUpCatalogCallbacks {
     onDropRemove?: (matchUpId: string) => void;
     /** Forwarded to every card as `MatchUpCardOptions.renderExtra`. See that contract. */
     renderCardExtra?: (matchUp: CatalogMatchUpItem) => HTMLElement | null;
+    /** Forwarded to every card as `MatchUpCardOptions.relatedMatchUpIds`. See that contract. */
+    relatedMatchUpIds?: (matchUp: CatalogMatchUpItem) => string[];
 }
 export declare function buildMatchUpCatalog(callbacks: MatchUpCatalogCallbacks): UIPanel<SchedulePageState>;

package/dist/components/schedule-page/ui/matchUpHighlight.d.ts

@@ -0,0 +1,46 @@
+/**
+ * Schedule page — "related matchUp" highlighting.
+ *
+ * Hovering a catalog card lights up the matchUps it depends on wherever they
+ * appear: court-grid cells, other cards, the active strip. Anything carrying
+ * `data-matchup-id` participates, which is every surface on the page, so no
+ * registry is needed — the document already knows where each matchUp is drawn.
+ *
+ * ── Why this is not the conflict highlight ──
+ *
+ * `scheduleGridCell.ts` already highlights on hover, driven by `issueIds` from
+ * `proConflicts`, and paints amber. That relation is *conflict*: two matchUps
+ * that cannot both stand. The relation a catalog card carries is different and
+ * usually benign — the quarterfinal this semifinal is waiting on, the match a
+ * player walked off an hour ago. Painting those amber would teach the operator
+ * that a normal draw is full of conflicts, so this is a separate class with a
+ * separate colour, and the two can be lit at once without lying about either.
+ *
+ * The consumer supplies the relation: this component sees one matchUp at a time
+ * and could not compute "waiting on" if it wanted to.
+ */
+export declare const RELATED_HIGHLIGHT = "spl-related-highlight";
+/**
+ * Drop every related highlight in the document.
+ *
+ * Exported because `mouseleave` is not guaranteed to fire: the catalog rebuilds
+ * its cards on every state change, and a card removed while the pointer is over
+ * it never fires one — which would strand the highlight until the next hover
+ * happened to clear it. Consumers that rebuild cards themselves call this first.
+ */
+export declare function clearRelatedHighlight(): void;
+/** Light up every element drawn for one of `matchUpIds`. Clears any previous set first. */
+export declare function applyRelatedHighlight(matchUpIds: string[]): void;
+/**
+ * Wire hover highlighting onto one card.
+ *
+ * The relation is resolved on `mouseenter` rather than at build time: it depends
+ * on tournament state that moves under a card which may sit unrebuilt for
+ * minutes, and resolving it per hover costs one pass instead of one per card in
+ * every render.
+ *
+ * `dragstart` clears as well — a card being dragged is about to be re-parented
+ * by the browser, and a highlight left standing behind it reads as a result of
+ * the drop rather than a leftover of the hover.
+ */
+export declare function attachRelatedHighlight(card: HTMLElement, resolve: () => string[]): void;