Multiple "type" within "series"

[humphreylee]

I’ve observed that ECharts allows for multiple “types” within a “series” in examples like this one. Additionally, different “types” can be mixed within a single series, as shown in this example. I believe there are benefits to this approach. However, I’ve tried implementing this in Charming without success so far. Is it possible to achieve this in Charming?

[LukaOber]

I don't understand what you mean. In both of your examples, each series only has one type.
You can have multiple series in charming by repeatedly calling .series()

First example, there are three scatter series.

Chart::new()
  .series(Scatter::new())
  .series(Scatter::new())
  .series(Scatter::new());

Second example, one scatter series and one line series.

Chart::new()
  .series(Scatter::new())
  .series(Line::new());

[humphreylee]

Currently, the approach involves calling .series() for each series individually. I may have misunderstood, thinking it could be translated as follows:

Chart::new()
  .series(
        Scatter::new(), 
        Line::new()
  );

This example includes the following code snippet, suggesting an array/vector/tupple of series types, which also can share common properties, such as dataset.

series: [
    {
      name: 'scatter',
      type: 'scatter',
      datasetIndex: 0
    },
    {
      name: 'line',
      type: 'line',
      smooth: true,
      datasetIndex: 1,
      symbolSize: 0.1,
      symbol: 'circle',
      label: { show: true, fontSize: 16 },
      labelLayout: { dx: -20 },
      encode: { label: 2, tooltip: 1 }
    }
  ]

[LukaOber]

These are two separate series, and dataset is set on Chart. (I think)

[humphreylee]

It is unequivocal that these are two distinct series. The .series() function (as a function) in Charming may present a limitation, in contrast to ECharts, which utilizes a JSON configuration format.”

There is a comparable ECharts wrapper available in the Go language (go-echarts), which saw early contributions from Zhang, that functions in a similar manner.

[LukaOber]

I don't think a json configuration is better. They are different approaches. The json format is way simpler to implement, offers basically all options but the implementation here provides type safety. It's a tradeoff.

[humphreylee]

the implementation here provides type safety
👍