Skip to content

refactor(color): compute continuous color domain via series plugins#642

Open
korvin89 wants to merge 1 commit into
mainfrom
feat/color-domain-to-plugins
Open

refactor(color): compute continuous color domain via series plugins#642
korvin89 wants to merge 1 commit into
mainfrom
feat/color-domain-to-plugins

Conversation

@korvin89

Copy link
Copy Markdown
Collaborator

🤖 AI generated

Description

getDomainForContinuousColorScale switched over the series type, so a new type
meant editing core/utils/color.ts. The per-point color value now comes from the
type's own plugin. Part of the ongoing pluginization effort.

What changed

  • SeriesPlugin: optional getColorValue?(data). Core delegates via
    getSeriesPlugin(type).getColorValue?.(...) instead of switching.
  • Implemented in the 10 color-capable plugins, same field as before: y
    (line/area/bar-x/waterfall/scatter), x (bar-y), value (pie/heatmap/funnel),
    |x1 - x0| (x-range). treemap/sankey/radar keep no method and still throw.
  • Added a unit test (registers plugins via import '../../../plugins').

Behavior

Unchanged — same mapping, same [min, max], same error for unsupported types.

@gravity-ui

gravity-ui Bot commented Jun 23, 2026

Copy link
Copy Markdown

📖 Docs Preview is ready.

@gravity-ui-bot

Copy link
Copy Markdown
Contributor

Preview is ready.

@gravity-ui

gravity-ui Bot commented Jun 23, 2026

Copy link
Copy Markdown

Visual Tests Report is ready.
Performance Tests Report is ready.

@korvin89 korvin89 marked this pull request as ready for review June 23, 2026 20:25
@korvin89 korvin89 requested a review from kuzmadom as a code owner June 23, 2026 20:25
Comment thread src/core/series/plugin.ts
* Called by `getDomainForContinuousColorScale` over the raw series data (before shape data is prepared).
* Omit for types that do not support a continuous color scale (e.g. treemap, sankey, radar).
*/
getColorValue?(data: T['data'][number]): number;

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It might be beneficial to group these methods into logical blocks, similar to how it's done with the tooltip. Since the list of functions is growing, adding a bit of structure would prevent the flat list from becoming difficult to read.

@@ -0,0 +1,129 @@
// Populate the series registry so getSeriesPlugin works (see plugin registration gotcha).

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we have to write this for all tests? Can you put it in a general setup?


type Series = ChartData['series']['data'];

describe('utils/color/getDomainForContinuousColorScale', () => {

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It might be better to avoid tying test names to file paths. When directories change, keeping test names in sync can be easily overlooked, which might lead to outdated or confusing test names in the future.

validateXYSeries({series, xAxis, yAxis});
validateStacking({series});
},
getColorValue: (d) => Number(d.x),

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If colorValue is strictly meant to be a number, it might be better practice to handle the type casting outside the plugin closure rather than inside it.

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.

3 participants