import type { ColumnDef } from '../types/column.types';
import type { ColumnRendererMap, DisplayRendererFn } from '../types/renderer.types';
import type { BaseRendererOptions, BuiltInRendererDefinition } from '../types/built-in-renderer.types';
/**
 * Resolves a single rendering slot for a column, e.g.
 * `resolveColumnRenderer(colDef, 'display')`.
 *
 * This is the single entry point every renderer/engine touchpoint uses to read
 * `ColumnDef.renderer` — keeping the lookup in one documented place instead of
 * duplicated across call sites.
 *
 * Only the **slot-map form** has slots. When a column selects a built-in by
 * name, supplies a bare display function, or leaves `renderer` unset, every
 * slot here is `undefined` and the caller falls back to its own built-in
 * handling — which is exactly what those callers already did before named
 * renderers existed. The display slot specifically has a richer answer
 * available; see {@link resolveDisplayRenderer}.
 *
 * @returns The registered renderer function for `slot`, or `undefined` when the
 * column has no per-slot override and the caller should fall back to its
 * default built-in rendering.
 */
export declare function resolveColumnRenderer<K extends keyof ColumnRendererMap>(colDef: ColumnDef, slot: K): ColumnRendererMap[K] | undefined;
/**
 * How a column's cells should be drawn, and whether that output is patchable as
 * plain text.
 */
export interface ResolvedDisplayRenderer {
    /**
     * Which of the four outcomes this is.
     *
     * The three fields below are each meaningful for only some of them, so an
     * explicit discriminant beats forcing every consumer to re-derive one from
     * which properties happen to be absent.
     */
    readonly kind: 'custom' | 'builtin' | 'html' | 'text';
    /**
     * A custom display function, when the column supplies one. Takes precedence
     * over {@link builtIn} and is invoked with the existing
     * `DisplayRendererParams` contract.
     */
    readonly custom?: DisplayRendererFn;
    /** The built-in implementation, when no custom function applies. */
    readonly builtIn?: BuiltInRendererDefinition;
    /** Options declared alongside a built-in spec; `{}` otherwise. */
    readonly options: BaseRendererOptions;
    /**
     * `true` when the cell will be a single `.pg-cell__value` text node, which is
     * what lets the Virtual DOM patch it with one `textContent` write.
     *
     * @see BuiltInRendererDefinition.textOnly
     */
    readonly textOnly: boolean;
}
/**
 * Decides how one column's cells are drawn.
 *
 * ### Precedence
 * 1. `renderer` slot map's `display`
 * 2. `renderer` as a bare function
 * 3. `renderer` as a built-in name or `{ name, options }` spec
 * 4. `colDef.renderHtml`
 * 5. `colDef.valueFormatter`
 * 6. the built-in inferred from `colDef.type`
 *
 * Steps 1, 4, 5 and 6 reproduce the order that existed before named renderers
 * (display → renderHtml → valueFormatter → type switch), so no column that
 * works today changes. Steps 2 and 3 are new surface no existing column can
 * have.
 *
 * Whichever built-in is chosen — named or inferred — is configured from
 * `colDef.rendererParams`, layered under a spec's own `options`; see
 * {@link optionsFor}.
 *
 * A column with **both** an explicit built-in and a `valueFormatter` is not a
 * conflict: the renderer owns the presentation, and text-producing renderers
 * derive their string through `formatCellValue`, which already lets
 * `valueFormatter` win over the default formatting. The author's formatter is
 * honoured inside the renderer they asked for.
 *
 * Not memoised. This runs once per cell build and once per cell adoption into
 * the Virtual DOM — never per frame — and caching against a `ColumnDef` would
 * buy nothing while adding invalidation risk, since those objects are mutated
 * in place elsewhere (`pinned`, `width`, `locked`).
 *
 * @param colDef - The column to resolve.
 * @returns The renderer to use, plus its text-patchability.
 */
export declare function resolveDisplayRenderer(colDef: ColumnDef): ResolvedDisplayRenderer;
/**
 * Turns one cell value into the text that column displays.
 *
 * `null` means "this value has no special text form" — the caller keeps its own
 * formatting for that cell.
 *
 * @see BuiltInRendererDefinition.toText
 */
export type DisplayTextFn = (value: unknown) => string | null;
/**
 * Compiles a column's display-text resolver, once, for the loops that need it
 * per row — clipboard export and filtering.
 *
 * Resolving the renderer is cheap but not free (it reads `ColumnDef.renderer`,
 * merges options and hits the registry), and filtering a million rows would pay
 * that per cell. Callers hoist this out of their row loop the same way
 * `ClipboardEngine` hoists its field-path descriptors.
 *
 * The `null` return is the important half of the contract: it says this column's
 * renderer does not transform its value at all, so the caller can skip the
 * per-cell call entirely rather than invoking a function that would only ever
 * answer `null`. Every column that is not explicitly text-transforming takes
 * that path, which is why adding this seam costs untransformed columns nothing.
 *
 * @param colDef - The column to compile for.
 * @returns A resolver, or `null` when the column has no text-transforming
 *   renderer.
 */
export declare function compileDisplayText(colDef: ColumnDef): DisplayTextFn | null;
//# sourceMappingURL=renderer-resolver.d.ts.map