import{type TemplateResult,type PropertyValues}from'lit';import{LyraElement}from'../../../internal/lyra-element.js';import{type ToolRendererRegistry,type ToolResultStatus}from'./registry.js';import'../../overlays/skeleton/skeleton.class.js';import'../../utility/json-viewer/json-viewer.class.js';import'../../utility/copy-button/copy-button.class.js';
/** The two supported built-in fallback presentations. Invalid runtime values normalize to `json`. */
export type ToolResultFallback='json'|'text';export interface LyraToolResultViewEventMap{'lr-render-error':CustomEvent<{toolName:string;error:unknown;}>;}
/**
* `<lr-tool-result-view>` — renders a tool call's result via whichever
* custom renderer a host app has registered for it (see `registerToolRenderer()`
* in `registry.ts`), falling back to `<lr-json-viewer>` whenever no
* renderer matches, a candidate renderer's `matches()` predicate throws during
* dispatch, a renderer's optional `load()` rejects, or its `render()` throws.
* This component owns none of the actual visual weight of a
* populated tool result — that's entirely whatever the registered renderer
* returns; this is just the dispatch + fallback + loading-state shell.
*
* Dispatch runs against `registry` when set, otherwise against the
* module-level default registry `registerToolRenderer()` writes to — see
* `findToolRenderer()`'s two-step (exact name, then shape-based `matches()`)
* lookup order for the full rule.
*
* `fallback` implements two kinds: `"json"` (the default, an unconditional `<lr-json-viewer>`)
* and `"text"`, which renders a *string* `result` as preformatted text instead — falling back to
* the `"json"` behavior when `result` isn't a string, so setting `fallback="text"` defensively
* against an unpredictable result shape never renders broken output. `copyable` adds a
* copy-to-clipboard affordance to either fallback kind (forwarded to `<lr-json-viewer>`'s own
* `copyable` for `"json"`; a `<lr-copy-button>` alongside the text for `"text"`).
*
* A matched renderer's `render()` is also handed a 3rd `context` argument
* (`{ reportStatus }`) it can use to signal a non-throwing outcome (e.g. an application-level
* failure it still drew a real UI for) — see `ToolRenderContext` in `registry.ts`. This is purely
* additive: a pre-existing 2-arg `render(result, args)` function stays assignable unchanged, and a
* renderer that never calls `reportStatus` leaves `status` at its default, `'success'`.
*
* Assigning `registry` synchronously copies at most 10,000 entries into a frozen readonly facade.
* Later `set()`/`delete()` calls on the source map are not observed; create and assign a new map to
* update dispatch. Definition records are cloned and frozen; their callback identities are retained.
*
* @customElement lr-tool-result-view
* @event lr-render-error - `detail: { toolName, error }` — fired immediately
* before falling back to `<lr-json-viewer>`, whether because no renderer
* matched, a candidate renderer's `matches()` predicate threw during dispatch,
* a renderer's `load()` rejected, or its `render()` threw.
* @csspart base - The root wrapper around the resolved renderer's output (or the loading/fallback
* view). Exposes `aria-busy="true"` while a lazy renderer loads and `"false"` otherwise.
* @csspart fallback-text - The `<pre>` element for the `fallback="text"` kind's preformatted result text (only present in that mode).
* @csspart fallback-copy - The `<lr-copy-button>` shown when `copyable` is set alongside the `fallback="text"` kind (only present when both are set).
* @cssprop [--lr-tool-result-view-font=var(--lr-font-mono)] - Font family for the `fallback="text"` preformatted output.
* @status stable
* @since 4.0.0
*/
export declare class LyraToolResultView extends LyraElement<LyraToolResultViewEventMap>{protected static readonly ownedCollectionProperties:readonly string[];static styles:import("lit").CSSResultGroup[];static properties:{fallback:{reflect:boolean;noAccessor:boolean;};};
/** Custom registry to dispatch against instead of the module-level default one (see `registry.ts`). */
registry?:ToolRendererRegistry;
/** The tool's name — the primary dispatch key (see `findToolRenderer()`). */
toolName:string;
/** The tool call's result payload, handed to the matched renderer's `render()` (and to `matches()` for shape-based dispatch, and to the `<lr-json-viewer>` fallback). */
result:unknown;
/** The tool call's original arguments, if available — handed to the matched renderer's `render()` alongside `result`. */
args:unknown;private _fallback;
/** Fallback-kind selector — see the class doc's `fallback` paragraph for the full "json" vs "text" behavior. */
get fallback():ToolResultFallback;set fallback(next:ToolResultFallback);
/** Shows a copy-to-clipboard affordance alongside the fallback view (both `"json"` and `"text"` kinds) — forwarded to `<lr-json-viewer>`'s own `copyable`, or renders a `<lr-copy-button>` next to the text fallback. */
copyable:boolean;
/**
* The outcome of the currently-rendered result, as reported by the matched renderer's optional
* `context.reportStatus()` third `render()` argument (see `ToolRenderContext` in `registry.ts`).
* Reset to `'success'` immediately before every `render()` call, so a renderer that never calls
* `reportStatus` — including every pre-existing 2-arg renderer — leaves it at that default, and a
* later renderer that stays quiet doesn't inherit a stale outcome from a previous one. Reuses the
* same vocabulary as `<lr-tool-result-dialog>`'s own `status` property.
*/
status:ToolResultStatus;private renderState;private generation;private renderAttempt?;private resolvedLazy?;protected willUpdate(changed:PropertyValues):void;private resolve;private renderWith;private fail;render():TemplateResult;private renderFallback;}declare global{interface HTMLElementTagNameMap{'lr-tool-result-view':LyraToolResultView;}}