/** * `` — the cascading child selector, drawn. * * One select per level: the catalogue's roots, then that root's children, then * theirs, down to a leaf. It is deliberately the SAME control a person meets * as `Brand -> Model` inside a category's own characteristics, because under * the owner's navigation model a deep category IS a characteristic — the tiles * hand over here after level 2 and the gesture must not change at the handover. * * ── Selects, not a drill-down list ───────────────────────────────────────── * * The distinction is the whole control. `` shows ONE list * that replaces itself as you descend: to change a decision three levels up * you re-open the sheet and walk down again, and while the sheet is closed the * only thing on screen is the leaf. This field shows every level at once, each * still open to a different answer, and changing one drops the ones below it * because they are derived (`catalog/cascade.ts`) rather than remembered. * * On a phone that matters twice over: the answered levels ARE the trail, so * "where am I" costs no separate row, and a person who took a wrong turn fixes * the turn instead of restarting the journey. * * ── Every select searches ───────────────────────────────────────────────── * * `showSearch`, and not as a nicety: a live catalogue's top level has 130 rows * and its `Electronics` has 13. A select that made a person scroll 130 options * on a 390px screen would be the modal drill-down again, wearing a caret. The * filter runs over the RENDERED caption, so typing matches what is on screen * rather than the `category.` translation key underneath it * (`catalog/labels.ts`). * * ── The trail is gone, and the selects absorbed its one job ─────────────── * * There used to be a row of closable tags above the selects — one per * answered level. It was redundant with the selects BY CONSTRUCTION, which * this file said out loud and kept anyway, on the argument that popping a tag * is one tap where re-opening a select and picking its blank entry is three. * * That argument had already expired: every rung carries `allowClear`, so the * × inside the select pops that level in exactly one tap, from the control * that is already showing the answer. What the tags actually bought was a * second printing of the path, and the measurement is what settled it — the * phone's filter sheet opened on the chosen leaf's three names, and then the * same three names again in the selects under them: half a screen spent * restating one fact before the first control (walker D103; the composer's * step 3 was the same shape, D89). One path, printed once, in the controls * that can change it. * * ── What it does NOT draw ───────────────────────────────────────────────── * * A count beside an option, unless the host supplied one. See * `headless/CategoryCascade.tsx` for why no server can currently answer that * and why an invented number is worse than none. */ import type { ReactElement } from "react"; import type { UseCategoryCascadeOptions } from "../headless/CategoryCascade.js"; import type { ThemeModeProp } from "./types.js"; export interface CategoryCascadeFieldProps extends UseCategoryCascadeOptions, ThemeModeProp { /** * `"stack"` (default) puts one select per line — the composer's shape, and * the desktop filter rail's. * * `"inline"` lets them wrap side by side, which is what fits inside a filter * chip's sheet where the ladder is rarely more than two rungs. */ readonly layout?: "stack" | "inline"; /** * Print the verdict line under the control. Default `true`. * * The composer needs it — the whole attribute form is gated on reaching a * leaf, and a control that goes quiet without saying why is the thing * `ActionAvailability` exists to prevent. A filter chip does not: there the * narrowing is visible in the results themselves and the chip's own label * already carries the answer. */ readonly verdict?: boolean; } export declare function CategoryCascadeField(props: CategoryCascadeFieldProps): ReactElement; //# sourceMappingURL=CategoryCascadeField.d.ts.map