import { type TemplateResult } from 'lit';
import { RoxyDataElement } from '../utils/base-element.js';
/**
 * Generic fallback renderer. Accepts ANY OpenAPI response shape and renders
 * it via field-name heuristics so future spec additions render reasonably
 * without hand-wired components.
 *
 * Heuristic order:
 *   1. Primitive (string, number, boolean) -> single line.
 *   2. Array of primitives -> chip list.
 *   3. Array of objects with shared keys -> table.
 *   4. Object with title-like field -> card with key/value rows; object and
 *      object-array values promote to full-width sections below the rows so
 *      nested tables keep the whole container width.
 *   5. Otherwise -> definition list of all keys.
 *
 * Scalar display rules (shared by rows, chips, and table cells): numbers
 * round to 2 decimals, booleans read Yes/No, ISO dates and datetimes format
 * for the locale, SCREAMING_SNAKE enums humanize, http(s) strings link out.
 *
 * Every word this component writes goes through `this.t()`, which is not
 * optional politeness: `suppress()` already folds the API's localized values
 * into their canonical columns, so before the catalogue landed a Spanish page
 * read `Sol` and `Piscis` under `Yes`, `No` and `31 rows` in English. What a
 * catalogue CANNOT reach is the column headings, which come from the wire field
 * name through `humanize()` and are therefore computed per response; those stay
 * English on both this path and the PHP one, which at least keeps them
 * consistent with each other. The PHP twin has none of these strings yet, so
 * the JS and no-JS paths currently disagree on the chrome as well as the fold
 * (see lesson 6 for why that matters).
 *
 * When a schema declares an `x-roxy-ui` hint, a future dispatcher can opt
 * into a hand-tuned component instead of this fallback.
 */
type Json = string | number | boolean | null | Json[] | {
    [key: string]: Json;
};
export declare class RoxyData extends RoxyDataElement<Json> {
    static styles: import("lit").CSSResult[];
    /**
     * Internal recursion depth. Nested <roxy-data> instances inherit this from the parent and increment to guard against circular references in the input. Not part of the public API; do not set from consumer code.
     */
    depth: number;
    protected renderData(data: Json): TemplateResult<1>;
    private renderValue;
    private renderArray;
    private renderChips;
    private renderTable;
    /**
     * Drop the fields that are noise on a reading card, and fold each localized twin into the field it translates. See {@link SUPPRESS_NOISE} and {@link foldLocalized}.
     *
     * @remarks
     * The single funnel for BOTH render paths, the table and the object, which is why the fold belongs here: it is one call and no column-building or row-building code has to know the convention exists. Folding runs FIRST, so a field this then suppresses takes its translation with it rather than leaving `Type Localized` standing where `Type` was hidden.
     */
    private suppress;
    private renderObject;
    /**
     * A named block of nested data. Collapses into `<details>` once it carries more than {@link DETAILS_KEYS} keys, so one fat object (a 27-nakshatra map, a 12-house table) cannot bury the rest of the card under a wall of rows.
     *
     * @remarks
     * Deliberately carries no `part`. The heading here IS a response key, so the only name this block could take is computed, and `roxy-reference-card` is the one component allowed to derive a part at runtime (`catalog.test.ts` pins it as the only one). A bare `part="section"` is the other tempting option and is worse: the vocabulary pairs `section` with a specific name precisely so `::part(section patterns)` addresses ONE block, and a token that lands identically on every key of every response addresses none of them.
     */
    private renderSection;
    private renderField;
    private renderCell;
    private scalarTemplate;
    private formatScalar;
    private collectKeys;
}
declare global {
    interface HTMLElementTagNameMap {
        'roxy-data': RoxyData;
    }
}
export {};
//# sourceMappingURL=data.d.ts.map