import { type DataSource } from '@sisense/sdk-data';
import type { ChartDataOptions, PivotTableDataOptions } from '../../../domains/visualizations/core/chart-data-options/types';
import type { GenericDataOptions } from '../../../types';
import type { WidgetType } from '../components/widget/types';
/** Union of every widget's `dataOptions` shape (chart, pivot, custom). */
type WidgetDataOptions = ChartDataOptions | PivotTableDataOptions | GenericDataOptions;
/**
 * Resolves a stable, unique `entityId` for a widget tracking event.
 *
 * Prefers the widget's own `id` (the Fusion widget OID when loaded via `WidgetById` /
 * `DashboardById`, or the user-supplied id when composed). When no id is available — e.g. a
 * standalone `<ChartWidget>` — it falls back to a deterministic hash of the widget's identity:
 * its type, name, title, the column names of its `dataOptions`, and its data source. Two
 * structurally identical standalone widgets therefore resolve to the same id, which is the
 * desired behavior for adoption tracking. The fallback is prefixed with `hash:` so downstream
 * consumers can tell a generated identifier apart from a real widget id/OID.
 *
 * Typed with a generic + intersection so callers pass their concrete widget prop type while the
 * optional `id` / `dataOptions` / `dataSource` are read uniformly (e.g. `TextWidgetProps` declares
 * none of them).
 *
 * @internal
 */
export declare const getWidgetEntityId: <P extends object>(props: P & {
    id?: string | undefined;
    title?: string | undefined;
    dataOptions?: WidgetDataOptions | undefined;
    dataSource?: DataSource | undefined;
}, widgetType: WidgetType, widgetName: string) => string;
export {};