@liiift-studio/sanity-visitor-insights 0.24.0 → 0.26.0

package/dist/index.d.mts

@@ -3,38 +3,6 @@ import React from 'react';
 import { R as ReportEnvelope, a as ReportName, b as RangeKey, M as MetricValue, A as AcquisitionData, c as MeasurementHealthData, D as DiagnosticReport, J as JourneyData, T as TypefaceInterestData } from './ranges-BUZuS1c-.mjs';
 export { C as CaptureBasis, d as CaptureEstimate, e as CaptureModel, f as CheckStatus, g as Coverage, h as CrossSourceDay, i as DailyPoint, j as DateRange, k as DiagnosticCheck, E as EmailCampaign, l as EventCutover, m as JourneyOutcome, n as JourneyStep, L as LandingPage, o as LicenceTierRow, P as PREEXISTING, p as REPORT_NAMES, q as ReportError, S as SiteAnalyticsConfig, r as SourceName, s as SourceRow, t as SourceStatus, u as TimelineEvent, v as TypefaceInterestRow, U as UnavailableReason, w as coverageForRange, x as estimated, y as isReportName, z as ok, B as partial, F as previousRange, G as resolveRange, H as unavailable, I as validateSiteConfig, K as valueOrNull } from './ranges-BUZuS1c-.mjs';
 
-/**
- * The Visitor Insights Studio tool.
- *
- * One range control drives every panel, implemented once here as a proper radiogroup with
- * roving tabindex — repeating a bespoke toggle per panel is how keyboard behaviour ends up
- * inconsistent between them.
- */
-
-/** Options supplied by the plugin config, carried on the Sanity tool definition. */
-interface VisitorInsightsToolProps {
-    apiBaseUrl: string;
-    siteLabel: string;
-}
-/**
- * What Sanity actually hands a tool component.
- *
- * Sanity does NOT spread a tool's `options` onto its component's props — it passes the whole tool
- * definition as `tool`, with the options nested inside. Destructuring `apiBaseUrl` straight off
- * props therefore yields undefined, and the first thing useReport does with it is call .replace(),
- * so every panel failed with "Cannot read properties of undefined (reading 'replace')".
- *
- * Both shapes are accepted: the nested one because that is what the Studio passes, and the flat one
- * because the component is exported for direct use and is mounted that way in tests.
- */
-interface VisitorInsightsToolComponentProps extends Partial<VisitorInsightsToolProps> {
-    tool?: {
-        options?: Partial<VisitorInsightsToolProps>;
-    };
-}
-/** The tool itself. */
-declare function VisitorInsightsTool(props: VisitorInsightsToolComponentProps): React.ReactElement;
-
 /**
  * Data hook for the Studio panels.
  *
@@ -101,6 +69,37 @@ declare function useReport<T>({ apiBaseUrl, report, range, custom, enabled }: Us
     reload: () => void;
 };
 
+/**
+ * The Visitor Insights Studio tool.
+ *
+ * One range control drives every panel, implemented once here as a proper radiogroup with
+ * roving tabindex — repeating a bespoke toggle per panel is how keyboard behaviour ends up
+ * inconsistent between them.
+ */
+
+/** Options supplied by the plugin config, carried on the Sanity tool definition. */
+interface VisitorInsightsToolProps {
+    apiBaseUrl: string;
+    siteLabel: string;
+}
+/**
+ * What Sanity actually hands a tool component.
+ *
+ * Sanity does NOT spread a tool's `options` onto its component's props — it passes the whole tool
+ * definition as `tool`, with the options nested inside. Destructuring `apiBaseUrl` straight off
+ * props therefore yields undefined, and the first thing useReport does with it is call .replace(),
+ * so every panel failed with "Cannot read properties of undefined (reading 'replace')".
+ *
+ * Both shapes are accepted: the nested one because that is what the Studio passes, and the flat one
+ * because the component is exported for direct use and is mounted that way in tests.
+ */
+interface VisitorInsightsToolComponentProps extends Partial<VisitorInsightsToolProps> {
+    tool?: {
+        options?: Partial<VisitorInsightsToolProps>;
+    };
+}
+declare function VisitorInsightsTool(props: VisitorInsightsToolComponentProps): React.ReactElement;
+
 /**
  * Shared renderers for metric values and comparison bars.
  *
@@ -200,6 +199,10 @@ interface ChartDataProps<Row> {
     columns: Array<SortColumn<Row>>;
     rowKey: (row: Row) => string;
     exportName?: string;
+    /** A line above the table, for anything a column header cannot carry. */
+    note?: string;
+    /** Which column to filter on, if the table should offer a filter box. */
+    filterOn?: (row: Row) => string;
 }
 /**
  * The figures behind a chart, as a table, collapsed by default.
@@ -213,7 +216,7 @@ interface ChartDataProps<Row> {
  * axis type at any size; and anyone who wants these numbers in a spreadsheet, since the table
  * brings sorting and CSV copy with it. Collapsed, so it costs a sighted reader one line.
  */
-declare function ChartData<Row>({ label, rows, columns, rowKey, exportName }: ChartDataProps<Row>): React.ReactElement | null;
+declare function ChartData<Row>({ label, rows, columns, rowKey, exportName, note, filterOn }: ChartDataProps<Row>): React.ReactElement | null;
 /** One bar of a proportion chart. */
 interface ProportionBar {
     key: string;

package/dist/index.d.ts

@@ -3,38 +3,6 @@ import React from 'react';
 import { R as ReportEnvelope, a as ReportName, b as RangeKey, M as MetricValue, A as AcquisitionData, c as MeasurementHealthData, D as DiagnosticReport, J as JourneyData, T as TypefaceInterestData } from './ranges-BUZuS1c-.js';
 export { C as CaptureBasis, d as CaptureEstimate, e as CaptureModel, f as CheckStatus, g as Coverage, h as CrossSourceDay, i as DailyPoint, j as DateRange, k as DiagnosticCheck, E as EmailCampaign, l as EventCutover, m as JourneyOutcome, n as JourneyStep, L as LandingPage, o as LicenceTierRow, P as PREEXISTING, p as REPORT_NAMES, q as ReportError, S as SiteAnalyticsConfig, r as SourceName, s as SourceRow, t as SourceStatus, u as TimelineEvent, v as TypefaceInterestRow, U as UnavailableReason, w as coverageForRange, x as estimated, y as isReportName, z as ok, B as partial, F as previousRange, G as resolveRange, H as unavailable, I as validateSiteConfig, K as valueOrNull } from './ranges-BUZuS1c-.js';
 
-/**
- * The Visitor Insights Studio tool.
- *
- * One range control drives every panel, implemented once here as a proper radiogroup with
- * roving tabindex — repeating a bespoke toggle per panel is how keyboard behaviour ends up
- * inconsistent between them.
- */
-
-/** Options supplied by the plugin config, carried on the Sanity tool definition. */
-interface VisitorInsightsToolProps {
-    apiBaseUrl: string;
-    siteLabel: string;
-}
-/**
- * What Sanity actually hands a tool component.
- *
- * Sanity does NOT spread a tool's `options` onto its component's props — it passes the whole tool
- * definition as `tool`, with the options nested inside. Destructuring `apiBaseUrl` straight off
- * props therefore yields undefined, and the first thing useReport does with it is call .replace(),
- * so every panel failed with "Cannot read properties of undefined (reading 'replace')".
- *
- * Both shapes are accepted: the nested one because that is what the Studio passes, and the flat one
- * because the component is exported for direct use and is mounted that way in tests.
- */
-interface VisitorInsightsToolComponentProps extends Partial<VisitorInsightsToolProps> {
-    tool?: {
-        options?: Partial<VisitorInsightsToolProps>;
-    };
-}
-/** The tool itself. */
-declare function VisitorInsightsTool(props: VisitorInsightsToolComponentProps): React.ReactElement;
-
 /**
  * Data hook for the Studio panels.
  *
@@ -101,6 +69,37 @@ declare function useReport<T>({ apiBaseUrl, report, range, custom, enabled }: Us
     reload: () => void;
 };
 
+/**
+ * The Visitor Insights Studio tool.
+ *
+ * One range control drives every panel, implemented once here as a proper radiogroup with
+ * roving tabindex — repeating a bespoke toggle per panel is how keyboard behaviour ends up
+ * inconsistent between them.
+ */
+
+/** Options supplied by the plugin config, carried on the Sanity tool definition. */
+interface VisitorInsightsToolProps {
+    apiBaseUrl: string;
+    siteLabel: string;
+}
+/**
+ * What Sanity actually hands a tool component.
+ *
+ * Sanity does NOT spread a tool's `options` onto its component's props — it passes the whole tool
+ * definition as `tool`, with the options nested inside. Destructuring `apiBaseUrl` straight off
+ * props therefore yields undefined, and the first thing useReport does with it is call .replace(),
+ * so every panel failed with "Cannot read properties of undefined (reading 'replace')".
+ *
+ * Both shapes are accepted: the nested one because that is what the Studio passes, and the flat one
+ * because the component is exported for direct use and is mounted that way in tests.
+ */
+interface VisitorInsightsToolComponentProps extends Partial<VisitorInsightsToolProps> {
+    tool?: {
+        options?: Partial<VisitorInsightsToolProps>;
+    };
+}
+declare function VisitorInsightsTool(props: VisitorInsightsToolComponentProps): React.ReactElement;
+
 /**
  * Shared renderers for metric values and comparison bars.
  *
@@ -200,6 +199,10 @@ interface ChartDataProps<Row> {
     columns: Array<SortColumn<Row>>;
     rowKey: (row: Row) => string;
     exportName?: string;
+    /** A line above the table, for anything a column header cannot carry. */
+    note?: string;
+    /** Which column to filter on, if the table should offer a filter box. */
+    filterOn?: (row: Row) => string;
 }
 /**
  * The figures behind a chart, as a table, collapsed by default.
@@ -213,7 +216,7 @@ interface ChartDataProps<Row> {
  * axis type at any size; and anyone who wants these numbers in a spreadsheet, since the table
  * brings sorting and CSV copy with it. Collapsed, so it costs a sighted reader one line.
  */
-declare function ChartData<Row>({ label, rows, columns, rowKey, exportName }: ChartDataProps<Row>): React.ReactElement | null;
+declare function ChartData<Row>({ label, rows, columns, rowKey, exportName, note, filterOn }: ChartDataProps<Row>): React.ReactElement | null;
 /** One bar of a proportion chart. */
 interface ProportionBar {
     key: string;