Multiple line interpolate types on one graph?

[pcl]

I'd like to put multiple lines with different interpolate types onto one graph. Is that doable?

I was thinking it'd be nice to pass a list of hashes to the graph function, for example.

Here's some HTML that demonstrates the two graphs that I'd like to overlay: https://gist.github.com/pcl/01fd4df5dac3a0b1efed

[almossawi]

Not at the moment, sadly, but you could probably write an addon to do that.

[pcl]

One approach would be to change data_graphic() to leave the graph-global data in the top-level object, but push down the series-specific data into a list of sub-objects:

MG.data_graphic({
    target: "#selector",
    width: 1000,
    height: 200,
    markers: markers,
    graphs: [
        {
            data: data, // 'data' is a list with elements with date and y_1 keys
            x_accessor: "date",
            y_accessor: "y_1",
            interpolate: "step_after"
        },
        {
            data: data, // here, 'data' also contains elements with y_2 keys
            x_accessor: "date",
            y_accessor: "y_2",
            interpolate: "linear"
        }
    ]);

Another approach would be to support lists for the series-specific data:

MG.data_graphic({
    target: "#selector",
    width: 1000,
    height: 200,
    markers: markers,
    data: data,
    x_accessor: "date",
    y_accessor: [ "y_1", "y_2" ],
    interpolate: [ "step_after", "linear" ]);

The latter seems to be the precedent in the MG API currently, but moving to the former seems like it'd probably simplify these sorts of problems moving forward.

Do you have a strong preference for one approach versus the other?

Also, are either of these approaches really within the realm of an addon, or is it better for me to just write a PR against the core code?

[almossawi]

Yes, I think a PR would make sense. Either works for me. @hamilton do you have a particular preference?

Thanks.

[hamilton]

My preference is toward the latter for the sake of flatness, which I think is actually a boon for the API in terms of both legibility, ease-of-learning, and maintainability (at the moment). Agreed with @almossawi that a PR for something like this seems like a worthwhile addition vs. an add-on. Great addition!