Bar Chart y1 and y2

[elghali]

I am trying to build a bar chart having some data, but i want for every bar to provide its starting Y1 and its finishing Y2, is there a way to do such as the following :

datasets: [
  {
    label: 'My First dataset',
    backgroundColor: 'rgba(255,99,132,0.2)',
    borderColor: 'rgba(255,99,132,1)',
    borderWidth: 1,
    hoverBackgroundColor: 'rgba(255,99,132,0.4)',
    hoverBorderColor: 'rgba(255,99,132,1)',
   data: [{'Y1':65,'Y2':45},
             {'Y1':60,'Y2':41},
             {'Y1':80,'Y2':25},
             {'Y1':55,'Y2':30},
             {'Y1':75,'Y2':41},
             {'Y1':66,'Y2':25},
             {'Y1':55,'Y2':22}
  }
]
};

[benmccann]

Not yet. We've had lots of requests for this though:
#4120
#4773
#3077
#2912
#3574

[benmccann]

Some things to consider:

• Do we want to try to support stacked bars? Do they make sense in this case?
• Chart.js typically expects that you pass in {x,y} values. For this we will have two y values (the top and bottom of the bar). I would like to propose these values be able to be passed in as h and l (for high and low)
• Linear and logarithmic scales would need to be aware of high and low values. Mostly for determineDataLimits and getLabelForIndex. See anywhere getRightValue is called in scale.linear.js and scale.logarithmic.js
• controller.bar.js would need to use the new low value instead of always using 0. I think in or around updateElementGeometry

[benmccann]

@simonbrunel @etimberg does this plan sound good to you?

[flaushi]

+1 that would be a great feature for us to have!

[simonbrunel]

My thoughts:

• yes, stacked bars should be supported, we will need to discuss about that logic
• y1 y2 are consistent with x and y, though it doesn't work well with horizontal bars, so we would also need to support x1 x2?! At some point, we should expose some kind of data parser / reader to avoid hard coding all combinations of data structure (y, y y2, y1 y2, h l, min max, etc.). For now we should use the most natural, consistent and not connotated names (aren't h and l financial related?).
• I think that's the worse point, it might complicate scales a lot (even the time scale) and we need backward compatibility on all public methods (some plugins / feature - e.g. filler - rely on these methods in a generic way).
• certainly :)

[benmccann]

• What does the low value mean for stacked bars? For the first bar, it's obviously the space between the axis and the bar. For subsequent bars, would it mean the space between the current bar and the previous bar?
• Yes, h and l are typically used in financial charts. Though being good for one use case doesn't make it bad for another. Also, the open-high-low-close charts used to display financial information can be used to display any timeseries and while most frequently used to display financial information are not restricted to the display of financial info. One benefit of h and l is that we would only need to support a single variation that works with both horizontal and vertical charts instead of x and y variations. Or another option would be to support them all (x1, y1, x2, y2, h, and l). There was a bug recently filed against the financial repo by someone who wanted to use the logarithmic scale. If we support h and l then that would be supported. If we choose not to support it then we would need to override the logarithmic scale and create a financialLogarithmic scale just for the purpose of supporting different letters and it would be non-intuitive to users that they have to specify a different scale type.

[simonbrunel]

I think the first bar will define the min value, then the height (max - min) of the other bars are stacked on top of the first one.

One benefit of h and l is that we would only need to support a single variation that works with both horizontal and vertical charts instead of x and y variations

That's the same with min & max ...

What I mean is that the core implementation should not be defined by some external / connotated concepts (such as the financial chart) but should stay generic and flexible. If h and l are the best generic choice that talks to everyone (not only financial devs), then it's fine, else we should pick better names (personally, h and l don't talk to me but min & max yes).

I don't think we should support all of them but instead provide a public way to parse data, then user (or plugin or external charts) can provide their own way to read data (of course that would be implemented in another PR).

[benmccann]

That all makes sense to me. Not so sure about the stacked bar behavior, but I don't use that chart type, so I don't have as much insight into it and don't have strong feelings about it.

[larsnystrom]

I think [start, end] tuples is the most straight-forward way to represent a timeline. But since a timeline can be "broken", it will have to be a list of such tuples where each element represents a piece of the timeline, i.e.

[
  [ start, end ],
  [ start, end ],
  ...
]

The start and end values could be either numbers, if the x-axis is numeric, or native Date objects, if the x-axis is a timeline.

[fanthos]

I am using [x1, x2, data] right now in my timeline chart implement. I prefer to use y1 and y2 because it should work better when using time scale.

[simonbrunel]

I'm not sure y1 and y2 should be candidates because it doesn't work well with horizontal charts.

Actually, instead of using named properties, why not using array as suggested by @larsnystrom?

labels: [x0, x1, ...]
datasets: [{
  data: [
    [min, max],  // eq. [start, end] or [l, h] 
    [min, max],
    [min, max],
    value,       // implicit min: 0 if value > 0 or
                 // implicit max: 0 if value < 0 
                 // (current implementation)
  ]
}]

// ... or ...

datasets: [{
  data: [
    {x: x0, y: [min, max]},
    {x: x1, y: [min, max]},
    {x: x1, y: value},
    ...
  ]
}]

[hameddhib-dydu]

#4120
http://jsfiddle.net/3fepvcte/
i try it and it works fine for me

[MartinDawson]

@dhib-dy That's not the fix for this issue. I can't remember why exactly but this definitely doesn't work for this issue because I tried it.

[benmccann]

We use named properties rather than arrays for the most part, so it would be a bit inconsistent to support only arrays. We have had a request for it (#4601). And in fact if we used the array notation above it would conflict with the request array notation in #4601 which put the x-value in the array

I think we should probably default to named properties for consistency with the other charts for now. I think support array notation might be an issue all on its own