Skip to content

fix: accept interface-typed rows in the chart generics#5

Open
DloomPlz wants to merge 1 commit into
Boring-Software-Inc:mainfrom
DloomPlz:fix/interface-rows
Open

fix: accept interface-typed rows in the chart generics#5
DloomPlz wants to merge 1 commit into
Boring-Software-Inc:mainfrom
DloomPlz:fix/interface-rows

Conversation

@DloomPlz

Copy link
Copy Markdown

Problem

The public chart generics are constrained to Record<string, unknown>, but TypeScript interfaces don't get an implicit index signature, so interface-typed rows fail to compile:

interface PricePoint { label: string; v: number }
const points: PricePoint[] = [...]

<AreaChart data={points} config={config}>   // ❌ TS2322
// Type 'PricePoint[]' is not assignable to type 'Row[]'.
//   Index signature for type 'string' is missing in type 'PricePoint'.

Type-alias rows work (aliases get the implicit signature), which makes the failure feel arbitrary to consumers.

Fix

Loosen the public generic constraint to object at the six chart roots, and cast at the controller boundary — the controllers only ever read row[key] for the configured series/name keys, so the cast is safe. Type-level only; no runtime change. Registry JSON regenerated with npm run build.

TData extends Record<string, unknown> rejects interface rows — interfaces
don't get an implicit index signature in TypeScript, so e.g.

  interface PricePoint { label: string; v: number }
  <AreaChart data={points} …>   // TS2322: index signature missing

Loosen the public generic constraint to object at the six chart roots and
cast at the controller boundary (the controllers only read row[key] for
configured keys). Type-level only — no runtime change.

Registry JSON regenerated via npm run build.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant