// This file was generated by [ts-rs](https://github.com/Aleph-Alpha/ts-rs). Do not edit this file manually.
import type { Aggregate } from "./Aggregate.js";
import type { Expressions } from "./Expressions.js";
import type { Filter } from "./Filter.js";
import type { FilterReducer } from "./FilterReducer.js";
import type { GroupRollupMode } from "./GroupRollupMode.js";
import type { OptionalUpdate } from "./OptionalUpdate.js";
import type { Sort } from "./Sort.js";
import type { SplitRollupMode } from "./SplitRollupMode.js";
import type { Windows } from "./Windows.js";
import type { JsonValue } from "./serde_json/JsonValue.js";

export type ViewerConfigUpdate = { 
/**
 * The `@perspective-dev/viewer` version a saved config was written
 * by, used to migrate older tokens. Omit it — the viewer stamps
 * the current version on save.
 */
version?: OptionalUpdate<string>, 
/**
 * Name of the visualization plugin to switch to, from the set
 * registered on the page (the `list_plugins` agent tool, or the
 * plugin picker). Changing it changes what the view fields MEAN:
 * `columns` is positional and every plugin reads the positions
 * differently, and `group_by`/`split_by` draw different things per
 * plugin — so read the new plugin's roles before writing `columns`
 * for it.
 */
plugin?: OptionalUpdate<string>, 
/**
 * Panel title, shown in its tab. `null` restores the default
 * title; omitting the field leaves the current one.
 */
title?: OptionalUpdate<string>, 
/**
 * Name of the `Table` to render, as hosted on this panel's
 * `Client`. Rebinding an existing panel to another table keeps the
 * rest of the config, so column names that do not exist in the new
 * table will fail validation.
 */
table?: OptionalUpdate<string>, 
/**
 * Theme NAME (e.g. `"Pro Dark"`) — not a CSS value. Valid names are
 * the Perspective themes loaded on the page, re-scanned by
 * `resetThemes()`. `null` selects the default.
 */
theme?: OptionalUpdate<string>, 
/**
 * Whether the settings sidebar is OPEN. Purely cosmetic chrome —
 * it does not affect what the viewer renders, and it is
 * element-level rather than per-panel.
 */
settings?: OptionalUpdate<boolean>, 
/**
 * Plugin-wide settings (as opposed to the per-column
 * [`Self::columns_config`]). The viewer passes these through
 * opaquely — their valid keys are defined by the ACTIVE plugin and
 * vary by plugin and by state, so query them with the
 * `get_style_schema` agent tool rather than guessing.
 */
plugin_config?: OptionalUpdate<{ [key in string]?: JsonValue }>, 
/**
 * Per-column styling — formatting, colors, and other per-column
 * controls — keyed by column name. Opaque to the viewer and
 * plugin-defined like [`Self::plugin_config`]; `get_style_schema`
 * reports the valid keys for a given column under the active
 * plugin.
 */
columns_config?: OptionalUpdate<{ [key in string]?: { [key in string]?: JsonValue } }>, 
/**
 * A group by _groups_ the dataset by the unique values of each column used
 * as a group by - a close analogue in SQL to the `GROUP BY` statement.
 * The underlying dataset is aggregated to show the values belonging to
 * each group, and a total row is calculated for each group, showing
 * the currently selected aggregated value (e.g. `sum`) of the column.
 * Group by are useful for hierarchies, categorizing data and
 * attributing values, i.e. showing the number of units sold based on
 * State and City. In Perspective, group by are represented as an array
 * of string column names to pivot, are applied in the order provided;
 * For example, a group by of `["State", "City", "Postal Code"]` shows
 * the values for each Postal Code, which are grouped by City,
 * which are in turn grouped by State.
 */
group_by?: Array<string>, 
/**
 * A split by _splits_ the dataset by the unique values of each column used
 * as a split by. The underlying dataset is not aggregated, and a new
 * column is created for each unique value of the split by. Each newly
 * created column contains the parts of the dataset that correspond to
 * the column header, i.e. a `View` that has `["State"]` as its split
 * by will have a new column for each state. In Perspective, Split By
 * are represented as an array of string column names to pivot.
 */
split_by?: Array<string>, 
/**
 * The `columns` property specifies which columns should be included in the
 * [`crate::View`]'s output. This allows users to show or hide a specific
 * subset of columns, as well as control the order in which columns
 * appear to the user. This is represented in Perspective as an array
 * of string column names.
 */
columns?: Array<string | null>, 
/**
 * The `filter` property specifies columns on which the query can be
 * filtered, returning rows that pass the specified filter condition.
 * This is analogous to the `WHERE` clause in SQL. There is no limit on
 * the number of columns where `filter` is applied, but the resulting
 * dataset is one that passes all the filter conditions, i.e. the
 * filters are joined with an `AND` condition.
 *
 * Perspective represents `filter` as an array of arrays, with the values
 * of each inner array being a string column name, a string filter
 * operator, and a filter operand in the type of the column.
 */
filter?: Array<Filter>, 
/**
 * The `sort` property specifies columns on which the query should be
 * sorted, analogous to `ORDER BY` in SQL. A column can be sorted
 * regardless of its data type, and sorts can be applied in ascending
 * or descending order. Perspective represents `sort` as an array of
 * arrays, with the values of each inner array being a string column
 * name and a string sort direction. When `column-pivots` are applied,
 * the additional sort directions `"col asc"` and `"col desc"` will
 * determine the order of pivot columns groups.
 *
 * `sort` is the ONLY thing that orders a `View`'s rows — without it
 * they keep the `Table`'s natural (insertion) order, which any
 * consumer reading rows sequentially will reflect. Not to be
 * confused with a window column's `order_by`, which orders rows
 * WITHIN a window frame and does not reorder the `View`.
 */
sort?: Array<Sort>, 
/**
 * The `expressions` property specifies _new_ columns in Perspective that
 * are created using existing column values or arbitary scalar values
 * defined within the expression. In `<perspective-viewer>`,
 * expressions are added using the "New Column" button in the side
 * panel.
 */
expressions?: Expressions, 
/**
 * The `windows` property declares ordered, partitioned rolling
 * computations (moving aggregates, cumulative sums) as _new_ columns
 * keyed by output alias (`{"name": {...spec}}`, symmetric with
 * `expressions`), analogous to SQL window functions. See
 * [`crate::config::WindowSpec`].
 */
windows?: Windows, 
/**
 * Aggregates perform a calculation over an entire column, and are
 * displayed when one or more [Group By](#group-by) are applied to the
 * `View`. Aggregates can be specified by the user, or Perspective will
 * use the following sensible default aggregates based on column type:
 *
 * - "sum" for `integer` and `float` columns
 * - "count" for all other columns
 *
 * Perspective provides a selection of aggregate functions that can be
 * applied to columns in the `View` constructor using a dictionary of
 * column name to aggregate function name.
 *
 * An aggregate also determines the column's RESULT TYPE, which need
 * not match the input: `"count"` yields an `integer` whatever it
 * counts, so a `date` column left on the default `"count"` is an
 * `integer` in the resulting `View` — no longer a date. Set an
 * aggregate that preserves the type (e.g. `"any"`, `"last"`) when
 * the original type matters, such as a date used as a chart axis.
 */
aggregates?: { [key in string]?: Aggregate }, group_by_depth?: number, filter_op?: FilterReducer, group_rollup_mode?: GroupRollupMode, split_rollup_mode?: SplitRollupMode, };