@tastic/hud 0.14.2 → 0.16.0

package/src/loadSkiaWeb.ts

@@ -1,7 +1,7 @@
-// Native counterpart to loadSkiaWeb.web.ts — Skia on native (via JSI, no WASM) is ready as soon as
+// Native counterpart to loadSkiaWeb.web.ts - Skia on native (via JSI, no WASM) is ready as soon as
 // the app's native module is linked, so there's nothing to actually wait on here. This file must
 // never import '@shopify/react-native-skia/src/web' (even conditionally behind a Platform.OS check):
-// that module pulls in canvaskit-wasm, which does `require('fs')` — a runtime check doesn't stop
+// that module pulls in canvaskit-wasm, which does `require('fs')` - a runtime check doesn't stop
 // Metro from statically resolving that import to build the native bundle graph, and Metro has no
 // `fs` for iOS/Android, so the build fails outright. Metro's own platform-extension resolution (this
 // file vs. loadSkiaWeb.web.ts) is what actually keeps the web-only module out of the native graph.

package/src/loadSkiaWeb.web.ts

@@ -1,9 +1,9 @@
 import { LoadSkiaWeb } from '@shopify/react-native-skia/src/web'
 
-// Skia's web target renders through CanvasKit, a WASM build of Skia fetched at runtime — nothing
+// Skia's web target renders through CanvasKit, a WASM build of Skia fetched at runtime - nothing
 // using @shopify/react-native-skia's React components can draw a single frame until this resolves.
 // Kept as a thin wrapper (rather than importing LoadSkiaWeb directly at call sites) purely so this
-// file's `.ts` counterpart, loadSkiaWeb.ts, gives native an identically-shaped async no-op — Metro's
+// file's `.ts` counterpart, loadSkiaWeb.ts, gives native an identically-shaped async no-op - Metro's
 // platform-extension resolution picks whichever one matches the bundle target, so canvaskit-wasm's
 // `require('fs')' never even gets resolved into a native/iOS/Android bundle.
 export function loadSkiaWeb(): Promise<void> {

package/src/overlayCard.ts

@@ -8,7 +8,7 @@ export interface OverlayCardColors {
 }
 
 // The literal-black/white-by-appearance "retro" formula this package's own BaseSettingsDialog and
-// ConfirmDialog each independently re-derived — deliberately NOT auto-paper's own (seed-color-tinted)
+// ConfirmDialog each independently re-derived - deliberately NOT auto-paper's own (seed-color-tinted)
 // background role, see either component's own "High-contrast retro look" comment for why. Every
 // fleet app's own Game-Over/Round-Over/Match-Over/Quit-confirmation overlay re-derives this same
 // three-or-four-line formula again, which is what this export exists to replace.
@@ -21,7 +21,7 @@ export function getOverlayCardColors(dark: boolean): OverlayCardColors {
   }
 }
 
-// Only the shell shape every overlay card shares (backdrop + card geometry) — deliberately not the
+// Only the shell shape every overlay card shares (backdrop + card geometry) - deliberately not the
 // title/body styling, which already legitimately varies by consumer (each app's own score/badge/zone
 // content). A consumer applies `{backgroundColor: cardBg, borderColor: cardBorder}` from
 // getOverlayCardColors on top of `card` itself, same as every existing call site already does. The
@@ -51,7 +51,7 @@ export const overlayStyles = StyleSheet.create({
 // Back) on the left, a contained primary on the right, each growing to split the row but never
 // narrower than 128. Moved here from ConfirmDialog when the how-to-play card needed the identical
 // row, so the two can't drift into different button shapes (the guide briefly shipped text-mode
-// Skip/Back — the only text buttons in the fleet).
+// Skip/Back - the only text buttons in the fleet).
 export const overlayActionStyles = StyleSheet.create({
   // minWidth (not flexBasis) is each button's real floor - whenever both fit side by side, flexGrow
   // still splits any leftover width evenly beyond that floor, same visual result as a plain flex: 1

package/src/useAutoAlign.ts

@@ -2,18 +2,18 @@ import { type ViewRotation } from '@tastic/core'
 import { RefObject, useCallback, useEffect, useRef, useState } from 'react'
 import { useWindowDimensions, View } from 'react-native'
 
-// Minimum breathing room between a popover's outer edge and the screen edge — matches the general
+// Minimum breathing room between a popover's outer edge and the screen edge - matches the general
 // "don't butt content right up against the bezel" margin used elsewhere in this app.
 const EDGE_MARGIN = 12
 
 export type PopoverAlign = 'left' | 'right' | 'center'
 export type PopoverVerticalAlign = 'below' | 'above'
-// Same set of values as @tastic/core's own ViewRotation — re-exported under this package's existing
+// Same set of values as @tastic/core's own ViewRotation - re-exported under this package's existing
 // name rather than switching every call site to import ViewRotation directly, since "popover
 // rotation" reads clearer at these call sites than the more general core name.
 export type PopoverRotation = ViewRotation
 
-// Same shape useAutoAlign itself returns — exported so a caller can substitute this package's own
+// Same shape useAutoAlign itself returns - exported so a caller can substitute this package's own
 // plain, screen-edge-aware placement wholesale via a component's own `alignOverride` prop (see
 // LabeledDropdown's, SectionedDropdown's, and InlineColorPicker's own `alignOverride`), most often
 // with useZoneClampedAlign's result for a popover living inside a @tastic/split-screen zone, where
@@ -31,13 +31,13 @@ export interface AlignResult {
 
 // Reflects a rect from the PRE-rotation layout frame measureInWindow actually reports (see
 // useAutoAlign's own comment below for why that's what it reports, not the post-rotation visual
-// position) into its true, post-rotation position — needed for a trigger sitting inside a
+// position) into its true, post-rotation position - needed for a trigger sitting inside a
 // @tastic/split-screen-style FakeLandscapeView, or any other ancestor rotated the same way (a bare
 // CSS `transform: rotate()`, not an actual OS-level orientation change).
 //
 // The pivot is always the window's own center, for every rotation amount: FakeLandscapeView (and
 // this package's own doc-recommended equivalent for a caller that rolls its own) always centers its
-// rotated container — width/height swapped first for ±90°, unchanged for 180° — within the original,
+// rotated container - width/height swapped first for ±90°, unchanged for 180° - within the original,
 // un-rotated screen bounds before applying the CSS rotation, so the transform's own effective pivot
 // lands at that shared center regardless of which of the three non-zero rotations it is.
 export function rotateRect(x: number, y: number, width: number, height: number, rotation: PopoverRotation, windowWidth: number, windowHeight: number): { x: number; y: number; width: number; height: number } {
@@ -46,7 +46,7 @@ export function rotateRect(x: number, y: number, width: number, height: number,
   const cy = windowHeight / 2
   const dx = x + width / 2 - cx
   const dy = y + height / 2 - cy
-  // Clockwise-positive about (cx, cy) — matches CSS's own rotate(deg) sign convention, which is
+  // Clockwise-positive about (cx, cy) - matches CSS's own rotate(deg) sign convention, which is
   // where every rotation value this ever receives ultimately comes from (getViewRotation and
   // FakeLandscapeView both already commit to that same convention).
   const [newDx, newDy, newWidth, newHeight] = rotation === 180 ? [-dx, -dy, width, height] : rotation === 90 ? [-dy, dx, height, width] : [dy, -dx, height, width]
@@ -54,35 +54,35 @@ export function rotateRect(x: number, y: number, width: number, height: number,
 }
 
 // Measures a trigger's on-screen position (via measureInWindow) and picks whichever alignment keeps
-// a popover of `contentWidth`×`contentHeight` from overflowing a screen edge — horizontally
-// (left/right/center, preferring center) and vertically (below/above, preferring below — the usual
-// case — but flipping to above when the trigger doesn't have enough room underneath it, which is
+// a popover of `contentWidth`×`contentHeight` from overflowing a screen edge - horizontally
+// (left/right/center, preferring center) and vertically (below/above, preferring below - the usual
+// case - but flipping to above when the trigger doesn't have enough room underneath it, which is
 // what a short landscape screen with the trigger row near the top actually runs into).
 //
-// measureInWindow resolves the trigger's PRE-transform layout frame — confirmed against a real
+// measureInWindow resolves the trigger's PRE-transform layout frame - confirmed against a real
 // rotated screen, not just reasoned about: an earlier version of this comment claimed the opposite
 // (that measureInWindow "resolves post-transform"), which is what let a real bug ship unnoticed,
 // since nothing here ever actually exercised a rotated case to catch that claim being wrong (see
 // this file's own test suite, which now does). A plain `onLayout` reports the same pre-transform
-// frame — there is no plain RN layout API that reports a transformed descendant's true visual
+// frame - there is no plain RN layout API that reports a transformed descendant's true visual
 // position, which is exactly why `rotation` below exists: it's the one piece of information this
 // hook cannot recover from measurement alone, since Yoga's layout pass and a CSS `transform` are
 // deliberately independent stages, so the caller has to supply it.
 //
-// `rotation` defaults to 0 (measureInWindow's raw result used as-is) — every existing caller that
+// `rotation` defaults to 0 (measureInWindow's raw result used as-is) - every existing caller that
 // never sits inside a rotated ancestor keeps behaving identically; only a caller that both (a) can
 // end up inside a @tastic/split-screen-style rotated zone and (b) knows which rotation is currently
 // live needs to pass it (see SectionedDropdown's own `rotation` prop for the wiring this expects).
 //
 // Also returns `maxHeight`: the actual room available in whichever vertical direction got picked.
-// Flipping above-vs-below only ever picks the *better* side — on a screen short enough that neither
+// Flipping above-vs-below only ever picks the *better* side - on a screen short enough that neither
 // side has room for the whole thing (the same landscape case, just more cramped), that's still not
 // enough on its own. The caller is expected to cap its content to this and let it scroll instead of
-// silently overflowing past the screen edge — this hook only decides where the popover opens, not
+// silently overflowing past the screen edge - this hook only decides where the popover opens, not
 // how its content copes with running out of room, since that's presentation-specific (a menu scrolls
 // its rows; other content might reasonably do something else).
 //
-// Re-measures on every open (not continuously) — the trigger's screen position can't change while
+// Re-measures on every open (not continuously) - the trigger's screen position can't change while
 // its own popover is showing anyway, so there's nothing to gain from tracking it beyond that.
 export function useAutoAlign(open: boolean, contentWidth: number, contentHeight: number, rotation: PopoverRotation = 0) {
   const triggerRef = useRef<View>(null)
@@ -90,17 +90,17 @@ export function useAutoAlign(open: boolean, contentWidth: number, contentHeight:
   const [align, setAlign] = useState<PopoverAlign>('center')
   const [verticalAlign, setVerticalAlign] = useState<PopoverVerticalAlign>('below')
   const [maxHeight, setMaxHeight] = useState<number>(contentHeight)
-  // False from the instant `open` goes true until this open's own measurement actually lands —
+  // False from the instant `open` goes true until this open's own measurement actually lands -
   // measureInWindow resolves via a native callback, not synchronously, so there's a real gap where
   // `align`/`verticalAlign` still hold whatever a *previous* open last measured (or the plain
   // 'center'/'below' guess, the very first time). Left ungated, the popover would mount and paint at
   // that stale/guessed position for one frame, then visibly jump the instant the real measurement
-  // lands — the caller is expected to hold the popover itself hidden (not just unmeasured content)
+  // lands - the caller is expected to hold the popover itself hidden (not just unmeasured content)
   // until this flips true, which is what actually avoids the flash rather than just relocating it.
   const [measured, setMeasured] = useState(false)
   // Detects the false->true edge of `open` *during render* (React's "adjusting state during render"
   // pattern) rather than in the effect below, specifically so `measured` is already false by the
-  // time this same render commits — an effect-based reset would still let one frame paint at the
+  // time this same render commits - an effect-based reset would still let one frame paint at the
   // stale/guessed alignment before the reset (and the eventual re-measurement) caught up.
   const [prevOpen, setPrevOpen] = useState(open)
   if (open !== prevOpen) {
@@ -115,12 +115,12 @@ export function useAutoAlign(open: boolean, contentWidth: number, contentHeight:
       const overflowsRight = centerX + contentWidth / 2 > windowWidth - EDGE_MARGIN
       const overflowsLeft = centerX - contentWidth / 2 < EDGE_MARGIN
       // Both directions overflowing means the popover is simply wider than the screen has room for
-      // either way — 'center' is the least-bad choice there (symmetric clipping beats asymmetric).
+      // either way - 'center' is the least-bad choice there (symmetric clipping beats asymmetric).
       if (overflowsRight && !overflowsLeft) setAlign('right')
       else if (overflowsLeft && !overflowsRight) setAlign('left')
       else setAlign('center')
 
-      // Below is the default/preferred direction — only flips to above when there's genuinely more
+      // Below is the default/preferred direction - only flips to above when there's genuinely more
       // room that way, not merely whenever below is imperfect, so a popover close to fitting either
       // way doesn't flip-flop from a one-pixel margin difference.
       const roomBelow = windowHeight - (y + triggerHeight) - EDGE_MARGIN
@@ -133,10 +133,10 @@ export function useAutoAlign(open: boolean, contentWidth: number, contentHeight:
   }, [contentWidth, contentHeight, windowWidth, windowHeight, rotation])
 
   // Re-measures whenever `open` flips true, and also if `measure` itself changes identity (i.e.
-  // contentWidth/contentHeight/windowWidth/windowHeight/rotation changed) while already open — e.g.
-  // a live window resize, or the device being physically turned while the popover is showing — so it
+  // contentWidth/contentHeight/windowWidth/windowHeight/rotation changed) while already open - e.g.
+  // a live window resize, or the device being physically turned while the popover is showing - so it
   // never goes stale while the popover is actually showing. `measured` only resets on a genuine
-  // (re)open, via the render-phase check above — not here on every re-measure, so an already-visible
+  // (re)open, via the render-phase check above - not here on every re-measure, so an already-visible
   // popover never flickers hidden again just because the window resized (or rotated) under it.
   useEffect(() => {
     if (open) measure()

package/src/usePopoverHost.ts

@@ -9,7 +9,7 @@ export interface PopoverHost {
 // Shared open/closed state for a small group of sibling popovers (e.g. one player panel's color
 // picker and the shared controls' dropdowns) so opening one closes any other already open in the
 // same group. Give each player's panel its own instance so opening a popover in one player's panel
-// never affects another player's — that independence is what lets two people edit their own setup
+// never affects another player's - that independence is what lets two people edit their own setup
 // at once on a split screen.
 export function usePopoverHost(): PopoverHost {
   const [openId, setOpenId] = useState<string | null>(null)

package/src/useZoneClampedAlign.ts

@@ -5,7 +5,7 @@ import { useSafeAreaInsets } from 'react-native-safe-area-context'
 
 import { PopoverRotation, PopoverVerticalAlign, useAutoAlign } from './useAutoAlign'
 
-// Matches useAutoAlign's own EDGE_MARGIN convention — not exported from that file, so re-declared
+// Matches useAutoAlign's own EDGE_MARGIN convention - not exported from that file, so re-declared
 // here rather than reaching into its internals.
 const EDGE_MARGIN = 12
 
@@ -15,63 +15,63 @@ interface OwnBounds {
 }
 
 // Wraps useAutoAlign with a zone-aware vertical decision for popovers that live inside a
-// @tastic/split-screen zone (see useZoneBounds' own doc) — a no-op outside one (e.g. a solo,
+// @tastic/split-screen zone (see useZoneBounds' own doc) - a no-op outside one (e.g. a solo,
 // non-split-screen screen), where useAutoAlign's own decision is returned untouched.
 //
 // useAutoAlign picks above-vs-below and its own maxHeight by comparing room against the *full
-// device window* — for a trigger inside a zone, that's wrong in a way a simple clamp on top can't
+// device window* - for a trigger inside a zone, that's wrong in a way a simple clamp on top can't
 // fix: capping its chosen direction after the fact still leaves it capable of *choosing* the
 // direction that points into the shared row (or the opposite player's own zone), which, once
-// correctly capped at that boundary, often has hardly any room at all — nearly useless rather than
+// correctly capped at that boundary, often has hardly any room at all - nearly useless rather than
 // merely mis-sized. The fix has to re-derive the whole vertical decision using the zone's real
 // boundary instead of the window edge, preferring whichever real-world direction is actually safe
-// (away from the shared row — that direction's room really is bounded by the screen edge, same as
+// (away from the shared row - that direction's room really is bounded by the screen edge, same as
 // useAutoAlign already assumes) and only reaching toward the shared row when the content doesn't
-// fit the safe side and the shared side genuinely has more room — the same "only flips when
+// fit the safe side and the shared side genuinely has more room - the same "only flips when
 // genuinely better" bias useAutoAlign itself uses, just comparing against the zone's own boundary
 // instead of the opposite screen edge.
 //
 // One more twist specific to p2's 180°-rotated zone: PopoverBody positions itself with plain
 // relative CSS (`top:'100%'`/`bottom:'100%'`) against its trigger, resolved in *local*
-// (pre-rotation) space and then rotated along with everything else in the zone — which inverts it,
+// (pre-rotation) space and then rotated along with everything else in the zone - which inverts it,
 // local 'below' the trigger paints as real-world *above* it once the whole zone flips 180°, and
 // vice versa. This hook's result has to be flipped back to the *local* label PopoverBody expects
 // whenever the zone itself is rotated (zone.rotated), or it ends up choosing the real-world
-// direction it meant to avoid — which is exactly the bug an earlier version of this hook had for
+// direction it meant to avoid - which is exactly the bug an earlier version of this hook had for
 // p2 specifically (it worked correctly for p1, which isn't rotated, and that's what made the bug
 // easy to miss during testing).
 //
 // CORRECTION (2026-09-18): the paragraph above used to also claim "this hook's own direction math
-// is all real-world (from measureInWindow, which — unlike onLayout — already resolves
-// post-transform)" — that's the exact claim useAutoAlign.ts's own doc documents as having already
+// is all real-world (from measureInWindow, which - unlike onLayout - already resolves
+// post-transform)" - that's the exact claim useAutoAlign.ts's own doc documents as having already
 // shipped one real, unnoticed bug once (measureInWindow reports the PRE-transform frame, not
 // post-transform; see that file's own comment). This hook still doesn't apply useAutoAlign's own
 // rotateRect(...) correction to its raw measureInWindow read below (awayRoom/towardRoom are
-// computed straight from the uncorrected y/height) — that's a real, currently-unfixed gap, left
+// computed straight from the uncorrected y/height) - that's a real, currently-unfixed gap, left
 // alone deliberately rather than guessed at: DualZoneLayout's own sharedEdgeY (see
 // React-Native-Split-Screen's DualZoneLayout.tsx, measureShared) has the identical uncorrected-
 // measureInWindow gap, since sharedRef sits under the same live-rotating outer FakeLandscapeView
-// every real caller wraps this in — and zone.rotated alone isn't sufficient to fix just this
+// every real caller wraps this in - and zone.rotated alone isn't sufficient to fix just this
 // hook's own half of it (it captures a trigger's own net rotation for p1/p2 specifically, which
 // happens to fully account for the outer rotation there, but sharedEdgeY's own correction needs
 // the outer rotation directly, which differs from zone.rotated for whichever seat zone.rotated is
 // currently true for). Correcting one side without the other risks making the comparison *more*
-// wrong, not less. No current caller in the fleet actually exercises this path today — every real
+// wrong, not less. No current caller in the fleet actually exercises this path today - every real
 // cpuDifficultyAlignOverride call site across the fleet is a confirmed no-op, never actually
-// rendering inside a live DualZoneLayout zone — so nothing currently miscalculates in practice, but
+// rendering inside a live DualZoneLayout zone - so nothing currently miscalculates in practice, but
 // this needs real rotated-zone test coverage (ideally live device testing, not just a unit test
 // stubbing measureInWindow) before either hook's room-size/direction math under live device
 // rotation is trustworthy.
 //
-// `rotation` IS threaded through below, though — that part's unambiguous and low-risk on its own:
+// `rotation` IS threaded through below, though - that part's unambiguous and low-risk on its own:
 // it only ever reaches useAutoAlign's own (rotation-aware) horizontal align decision, which is
 // exactly what a caller gets back verbatim via the `if (!zone) return auto` fallback whenever this
 // hook is used outside a zone at all (its own documented "safe to reach for even in a component
-// that might or might not end up inside one" case) — matching every sibling rotation-aware
+// that might or might not end up inside one" case) - matching every sibling rotation-aware
 // component's own default of an ambient `useRotation()` read when the caller omits it.
 //
 // The "away" direction's own room also has to stop at the physical safe area, not the raw window
-// edge — useAutoAlign's own windowHeight is the full device height, notch/status bar and home
+// edge - useAutoAlign's own windowHeight is the full device height, notch/status bar and home
 // indicator included, so left alone this hook's fix for the shared-row boundary would just trade
 // one overflow (into the other zone) for another (under the status bar, or behind the home
 // indicator). The toward-shared direction doesn't need this: sharedEdgeY already sits well inside
@@ -83,11 +83,11 @@ export function useZoneClampedAlign(open: boolean, contentWidth: number, content
   const insets = useSafeAreaInsets()
   const shouldMeasure = open && auto.measured && zone !== null
 
-  // null until this popover's own zone-aware measurement lands (see the effect below) — separate
+  // null until this popover's own zone-aware measurement lands (see the effect below) - separate
   // from auto.measured, which only covers useAutoAlign's own (zone-blind) measurement.
   const [ownBounds, setOwnBounds] = useState<OwnBounds | null>(null)
   // Resets synchronously during render, not in the effect below, the instant shouldMeasure flips
-  // either direction — same "adjust state during render" pattern useAutoAlign itself uses for its
+  // either direction - same "adjust state during render" pattern useAutoAlign itself uses for its
   // own measured reset (see that hook's own comment), so a stale ownBounds from a previous
   // open/zone never survives into a render it doesn't apply to, not even for the one frame before
   // an effect would otherwise catch up.
@@ -99,15 +99,15 @@ export function useZoneClampedAlign(open: boolean, contentWidth: number, content
 
   // Re-measures the same trigger node useAutoAlign itself measures, once *its* measurement has
   // landed (auto.measured, folded into shouldMeasure) so the ref is guaranteed mounted and settled.
-  // A second measureInWindow call on the same node, not a shared one with useAutoAlign — that
+  // A second measureInWindow call on the same node, not a shared one with useAutoAlign - that
   // hook's own measurement is fully internal to it, with nothing exposed to piggyback on beyond the
   // ref itself.
   useEffect(() => {
     if (!shouldMeasure) return
     auto.triggerRef.current?.measureInWindow((_x, y, _width, height) => {
       const belowShared = zone!.zoneSide === 'belowShared'
-      // Same shape as useAutoAlign's own roomBelow/roomAbove — this is the direction with nothing
-      // else between the popover and the real screen edge — but stopping at the safe area inset
+      // Same shape as useAutoAlign's own roomBelow/roomAbove - this is the direction with nothing
+      // else between the popover and the real screen edge - but stopping at the safe area inset
       // instead of the raw window edge (insets.top/insets.bottom are always real physical-device
       // edges, unaffected by any rotation applied further down the tree, so this is correct as-is
       // for p2's rotated zone too, not just p1's).
@@ -118,7 +118,7 @@ export function useZoneClampedAlign(open: boolean, contentWidth: number, content
       // Real-world direction, before any rotation compensation.
       let awaySide: PopoverVerticalAlign = belowShared ? 'below' : 'above'
       let towardSide: PopoverVerticalAlign = belowShared ? 'above' : 'below'
-      // See this hook's own doc — PopoverBody's local-then-rotate positioning inverts 'above'/
+      // See this hook's own doc - PopoverBody's local-then-rotate positioning inverts 'above'/
       // 'below' for a rotated zone, so the real-world label chosen above has to flip back to the
       // local one that actually produces it once painted.
       if (zone!.rotated) {