Skip to main content

Interface: DataPluginOf<TViewContext, TDataset>

Defined in: api/plugin.ts:71

A plugin that owns state — Fields, the edit hook, a store — and may paint it too.

The install site is where the state lives. A data half declares what shapes the Dataset's own construction, and a Dataset installs its plugins once. This arm installs on the Dataset for that reason. Every Gantt bound to that Dataset then runs view once, each with its own context, so I2 holds by construction.

Extends​

Type Parameters​

TViewContext​

TViewContext = unknown

TDataset​

TDataset = unknown

Properties​

aggregators?​

optional aggregators?: Readonly<Record<string, Aggregator>>

Defined in: api/plugin.ts:94

Aggregators this plugin adds, resolved before any Field naming one in rollUp.

fields?​

optional fields?: readonly Field & object[]

Defined in: api/plugin.ts:90

The same shape DatasetOptions.fields/fieldTypes/aggregators take (#496 grill round 3). Registered before any entry is read — alongside the Dataset's own, and before data() runs. So a flat value an entry carries for one of these keys survives new Dataset(...), the same way entries.load() already does. A duplicate key across the Dataset and every plugin throws DuplicateFieldKeyError, the same error two ordinary declarations sharing a key throw.

This is the one way a plugin declares: there is no ctx.fields.register door. A Field whose shape depends on this plugin's own options is built in the factory that returns this object — const costing = (opts) => ({ id: 'acme.costing', fields: [{ key: 'cost', ...opts }], data() {} }).

Each key must be one of this plugin's own props (PropsOf<TDataset>) or a core Field key. A typo such as { key: 'lockd' } on a definePlugin<LockProps> call fails to compile. A core-Field override such as { key: 'start' } still compiles. An untyped plugin (definePlugin({ … }), TDataset left as unknown) names any key.

fieldTypes?​

optional fieldTypes?: Readonly<Record<string, FieldType<unknown>>>

Defined in: api/plugin.ts:92

Named Field type bundles this plugin adds, resolved before any Field naming one.

hierarchySource?​

optional hierarchySource?: (next) => HierarchySource<PropsOf<TDataset>>

Defined in: api/plugin.ts:105

Declares the tree, instead of composing it from inside data() (ADR 0031). Call: definePlugin<PhaseProps>({ id, fields: [{ key: 'phaseId' }], hierarchySource: (next) => (entry) => entry.props.phaseId ?? next(entry) }) — "its hierarchy source is the entry's phase id, or the next source's answer."

Composes in setup order (resolveSetupOrder), the same order data() runs in. The first plugin wraps core's own storedParentSource, and a later plugin wraps the one before it — the last plugin answers first. Same composing idiom setExtender/setLockRule already use.

Parameters​

next​

HierarchySource<PropsOf<TDataset>>

Returns​

HierarchySource<PropsOf<TDataset>>

id​

id: string

Defined in: api/plugin.ts:34

Inherited from​

PluginIdentity.id

requires?​

optional requires?: readonly string[]

Defined in: api/plugin.ts:39

Plugin ids that must also be installed. Does not imply an order in the array: installation resolves setup order from requires alone, so [a, b] and [b, a] install identically. A required id nobody installs throws MissingPluginError. One list covers both halves (ADR 0019).

Inherited from​

PluginIdentity.requires

Methods​

data()?​

optional data(ctx): void | Disposer

Defined in: api/plugin.ts:75

Fields, the edit hook and the store. DOM-free, and runs once, on the finished Dataset. Optional: a plugin that only declares fields, fieldTypes, aggregators or hierarchySource needs no data() to run.

Parameters​

ctx​

DatasetPluginContextOf<TDataset>

Returns​

void | Disposer

view()?​

optional view(ctx): void | Disposer

Defined in: api/plugin.ts:96

The same half a chrome-only plugin fills. Optional: a headless plugin paints nothing.

Parameters​

ctx​

TViewContext

Returns​

void | Disposer