bar charts with category x-axis

Architecturally, some additional chart types can be supported as long as they conform to the following:

• X values must be numbers, increasing and unique
• Y values must be numbers, null or undefined for data gaps
• X and Y arrays must be equal length

const data = [
  [1566453600, 1566457260, 1566460860, 1566464460],   // x values
  [0.54,       0.15,       3.27,       7.51      ],   // series 1
  [12.85,      null,      13.65,      14.01      ],   // series 2
  [0.52,       1.25,       0.75,       null      ],   // series 3
];

this means we can support:

• line (numeric & time)
• line with custom markers (box plots, candlesticks, stock (OHLC)
• vt bar (column)
• hz bar

while the x-values have to be numeric, x labels can be text, so for something like this:

you could simply keep a map in app-space

let xCats = ["Censys", "Gharchive", "NYTimes"];

let data = [
  [   0,     1,     2],
  [3.09,   2.7,  2.92],
  [1.93,   1.6,  2.02],
  [1.06,  0.93,  1.22],
];

let opts = {
  scales: {
    x: {
      type: 'n'
    }
  },
  series: {
    y: [
      {label: "PyPyBaseline"},
      {label: "PyPyKeySringCaching"},
      {label: "PyPyMapNoCache"},
    ],
  },
  axes: {
    x: {
      values: (vals, space) => vals.map(v => xCats[v]),
    }
  }
}

[leeoniya]

i think this type of chart is a great complement to trend lines because it fundamentally represents a type of data that cannot be represented as a trendline; it literally doubles the possible use-cases while other types of charts mostly just show the same data in a different UX (stacked, ohcl/candlestick, area, pie). i already added numeric X-axis basically for free which now opens the possibility to use uPlot as a generic function plotter.

adding this would not impact perf since this will be able to use the existing data structure and not add new mem allocations. also, it will definitely use a different drawing loop compared to the lines. the main question here is one of additional code size. my gut feeling is that it can be done for an additional 1-3k with no perf impact, and that’s a worthwhile trade-off to me.

[leeoniya]

That looks intuitive enough.

it wasn’t to me!

i’ve switched it to be more uniform. among other refinements.

there is no more axis.tick and series.point for styling options; they have been rolled into single respective structures: series.points: {show: () => bool, width, size, stroke, fill} and i’ve renamed what used to be axis.ticks() to axis.split() since it applies to both ticks and grid, regardless of the visibility of either. the new axis.ticks: {show: bool, width, size, stroke} is used for styling and visibility.

next up is doing the same for cursor.points