@eonui/charts-canvas

@eonui/charts-canvas is the canvas renderer layer for the EonUI Mystique chart system. It draws chart families directly onto a CanvasRenderingContext2D, which makes it a good fit for dense charts, animation-heavy payloads, or surfaces where a single bitmap-backed chart is preferable to a large SVG tree.

Workspace Note

This folder currently documents the published package surface. The implementation source for @eonui/charts-canvas is consumed from npm in the EonUI app and is not mirrored into revamp/eonui/packages/charts-canvas yet.

Docs And Live Reference

Use this README for renderer-specific notes about the canvas path. For broader EonUI examples and product-level chart direction, refer to https://eonui.com.

Purpose

Use this package when you need:

• direct 2D canvas rendering
• large or dense data displays
• renderer control without the higher-level chart orchestration package
• a lower-level draw API that can be called inside an existing canvas lifecycle

What The Package Exposes Today

The current renderer includes:

• drawMystiqueChart()
• chart-family-specific draw functions such as line, bar, pie, heatmap, treemap, network, sankey, and funnel renderers
• shared palette and variant-overlay logic

It depends on @eonui/charts-core for type resolution, scales, and sample or manifest logic.

Install

npm install @eonui/charts-canvas

When To Reach For Canvas

Choose the canvas renderer when your chart surface values throughput, dense point rendering, and lightweight repaint cycles more than raw DOM inspectability. This is often the better option for:

• high-volume time-series views
• streaming dashboards
• compact sparkline-heavy interfaces
• cases where SVG node counts would become expensive

If you need exportable markup, richer DOM inspection, or easier static embedding, the SVG renderer may be a better fit.

Example 1: Draw a simple chart on a canvas

import { drawMystiqueChart } from '@eonui/charts-canvas';

const canvas = document.querySelector('canvas');
const ctx = canvas?.getContext('2d');

if (ctx) {
  drawMystiqueChart(
    ctx,
    'line',
    [
      { x: 1, y: 14, label: 'Jan' },
      { x: 2, y: 20, label: 'Feb' },
      { x: 3, y: 17, label: 'Mar' }
    ],
    720,
    320,
    'Revenue trend'
  );
}

Use this when:

• the host application already owns a canvas element
• you want chart drawing inside a custom dashboard shell
• you need deterministic drawing from plain data

Example 2: Draw a dense renderer variant

import { drawMystiqueChart } from '@eonui/charts-canvas';

drawMystiqueChart(
  ctx,
  'heatmap-drilldown-workbench',
  [
    { x: 0, y: 0, value: 32 },
    { x: 1, y: 0, value: 48 },
    { x: 0, y: 1, value: 61 },
    { x: 1, y: 1, value: 22 }
  ],
  720,
  360,
  'Signal density'
);

Use this when:

• a chart variant is better expressed on canvas than as SVG
• you need compact rendering for a dashboard card
• you want to prototype dense chart states quickly

Example 3: Use canvas as the dedicated renderer path

import { drawMystiqueChart } from '@eonui/charts-canvas';

function renderFrame(ctx: CanvasRenderingContext2D, data: Array<Record<string, unknown>>) {
  drawMystiqueChart(ctx, 'network-topology-health', data, 880, 460, 'Topology health');
}

Use this when:

• the surrounding app manages its own redraw cycle
• you need custom animation or scheduling on top of the Eon renderer
• you are embedding charts inside a larger canvas scene

Troubleshooting

• If the output looks blurry, scale the backing canvas for devicePixelRatio rather than drawing at CSS pixel size only.
• If labels clip at the edges, reserve enough internal padding before the draw call.
• If resize behavior is inconsistent, clear and redraw after the new dimensions are committed.
• If teams need DOM-level accessibility or easier snapshot testing, keep canvas as a selective renderer instead of the only chart output path.

Where This Package Fits

Start with @eonui/charts unless you specifically need renderer control. Reach for @eonui/charts-canvas when:

• the application already owns the canvas lifecycle
• you want a lower-level render function
• SVG markup generation is unnecessary overhead for the target surface

Current Limitations

• canvas output is not as inspectable as SVG markup
• accessibility and DOM-level introspection need higher-level wrappers or companion overlays
• consumer code still owns the canvas creation and sizing lifecycle

Future Prospects

The most valuable next steps are:

• exported bitmap helpers
• tighter animation presets
• offscreen-canvas and worker-friendly rendering paths
• renderer parity tooling against the SVG package