@clicktap/ui 0.40.11 → 0.40.12
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.
|
@@ -76,15 +76,19 @@ The cleanest fix is a type guard at the callback boundary:
|
|
|
76
76
|
> ```ts
|
|
77
77
|
> import type { Key } from 'react-aria-components';
|
|
78
78
|
>
|
|
79
|
-
> export function narrowKey<T extends { id
|
|
79
|
+
> export function narrowKey<T extends { id?: Key }>(
|
|
80
80
|
> value: Key | T | null,
|
|
81
81
|
> ): Key | null {
|
|
82
82
|
> if (value === null) return null;
|
|
83
83
|
> if (typeof value === 'string' || typeof value === 'number') return value;
|
|
84
|
-
> return value.id;
|
|
84
|
+
> return value.id ?? null;
|
|
85
85
|
> }
|
|
86
86
|
> ```
|
|
87
87
|
>
|
|
88
|
+
> The constraint is `{ id?: Key }` (optional), not `{ id: Key }`: real call sites often can't statically prove the item carries a **required** `id` — the inline versions cast `(value as { id?: string }).id` — so a required-`id` constraint fails to typecheck exactly where the helper is meant to be used. Returning `value.id ?? null` keeps the return type `Key | null`.
|
|
89
|
+
>
|
|
90
|
+
> **Behaviour note:** this helper returns `null` where an inline `value.id` could return `undefined`. Harmless for callers guarding with `?? ''` or `== null`, but it is a real behaviour change — name it if any call site distinguishes the two.
|
|
91
|
+
>
|
|
88
92
|
> Then each call site becomes `onSelectionChange={(v) => { const key = narrowKey(v); if (key !== null) selectItemByKey(key); }}`. We may upstream this helper to `@clicktap/ui/utils` in a future release; for now, ship it locally if your codebase has enough call sites to justify the abstraction.
|
|
89
93
|
|
|
90
94
|
### 2. If you need the full item, accept it directly
|