Closed caesarsol closed 4 years ago
I'll loop in a couple of people to comment. @zvonimirfras @cal-smith @tw15egan
My position is it's a good idea to support a tabular format of data and I've been waiting to see what Accurat would propose, however I don't see a significant advantage with the proposed data format.
I'm not a fan of the x
, y
, x2
, y2
idea since it doesn't clearly define where the data would land (is y left and y2 right? what if we have an RTL chart?)
I definitly prefer the tabular format over the current format - to my mind it's significantly clearer.
I agree with
I'm not a fan of the x, y, x2, y2 idea since it doesn't clearly define where the data would land (is y left and y2 right? what if we have an RTL chart?)
However we can sort that with some mapping options/functions ... something to the effect of:
data = [
{ supplier: 'foo inc', y: 66 }
{ supplier: 'bar corp', y: 25}
// ...
];
// in the options config
axis: {
bottom: {
map: (data) => data.supplier,
// ...
},
left: {
map: 'y',
// ...
}
}
so the type would look like map: string | (data) => any
. Should we need grouping or other values to order by, we can use the same type signature.
It should be fairly easy to write a function to map between the old format and a tabular format ... worst case it may also be feasible to support both.
@theiliad I've reported what you say under Problem 1, sorry if I wasn't clear! About the "non significant advantage", you may have a point. However, let me add to the pros the simplicity to add a three-dimensions chart such as the Heatmap, or the continuous-color-coded Scatterplot. I think the nested data structure for those could be pretty complicated.
@cal-smith thanks! I agree with you that we could also make function-based accessors, it's a very common pattern in lodash
so it definitely makes sense.
The only advantage I can think of using strings over functions is that they are JSON-serializable, but I don't know if that's something of importance for you.
The only advantage I can think of using strings over functions is that they are JSON-serializable, but I don't know if that's something of importance for you.
Definitely want to keep the possibility of JSON serialization, but there's no reason we can't support both strings and functions 👍
Done a long time ago
Hi, this is a proposal for @theiliad, about a change in the shape of the
data
object given as chart input.This is based on a pattern we often use at Accurat, which is to always start from non-nested datasets.
We find that tabular datasets are, for the fact that they avoid nesting:
lodash.groupBy
ord3.nest
)Follows two cases of conversions from old to new proposed format.
AS IS:
https://github.com/carbon-design-system/carbon-charts/blob/master/packages/core/demo/demo-data/line.ts#L81-L185
TO BE:
The proposed data format is basically the same shape of a CSV converted to JSON.
Problem 1: Column names
The two examples above use as columns, or object keys, the strings
group
x
y
, and some (y2
,color
) could be added in the future. But as @theiliad pointed out, the Carbon Charts are more generic and they don't rely on the fact that the horizontal axis is called X and the vertical Y.Another option could be to let the user specify the "axis - column" association as a configuration option. This would mean the dataset could have columns
[date, country, value]
and the configuration option could assign them:Problem 2: Backwards compatibility
We think that backward compatibility could be obtained by supporting both formats for a limited period of time, transforming one into the another.
Many things are still to be defined and we have many ideas, we are curious if anyone has any thoughts!
(cc @lucafalasco @serenaG @ilariaventurini)