Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bar Chart y1 and y2 #4863

Closed
elghali opened this issue Oct 18, 2017 · 24 comments
Closed

Bar Chart y1 and y2 #4863

elghali opened this issue Oct 18, 2017 · 24 comments

Comments

@elghali
Copy link

elghali commented Oct 18, 2017

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
Copy link
Contributor

benmccann commented Oct 18, 2017

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

@benmccann
Copy link
Contributor

benmccann commented Jan 10, 2018

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
Copy link
Contributor

benmccann commented Jan 16, 2018

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

@flaushi
Copy link

flaushi commented Jan 17, 2018

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

@simonbrunel
Copy link
Member

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
Copy link
Contributor

  • 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
Copy link
Member

simonbrunel commented Jan 17, 2018

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
Copy link
Contributor

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
Copy link

larsnystrom commented Jan 17, 2018

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
Copy link
Contributor

fanthos commented Jan 17, 2018

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
Copy link
Member

simonbrunel commented Jan 17, 2018

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
Copy link

hameddhib-dydu commented Jan 17, 2018

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

@MartinDawson
Copy link
Contributor

@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
Copy link
Contributor

benmccann commented Jan 18, 2018

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

@etimberg
Copy link
Member

I think supporting the formats @simonbrunel suggested above.

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

In terms of stacked bars, I'm not sure how that works. One idea is to consider two datasets, each with a min and max for each bar.

Dataset Min Max Stacked Min Stacked Max
0 min0 max0 min0 max0
1 min1 max1 max0 + min1 max0 + min1 + max1

@bobalazek
Copy link

Any news on this feature?

@benmccann
Copy link
Contributor

There's an open pull request implementing it: #6056

@marcuswindecker
Copy link

@benmccann, is there any ETA on when this might be merged and available in the npm package? This is basically the only hangup preventing us from being able to use chartjs for a project.

@benmccann
Copy link
Contributor

That PR is quite close to being merged. I'd imagine it will be part of the next release (2.9.0). I don't have an estimated date for when that might happen

@hoangngk
Copy link

@benmccann Hope it will be merged soon

@simonbrunel simonbrunel added this to the Version 2.9 milestone May 21, 2019
@simonbrunel
Copy link
Member

@bobalazek @marcuswindecker @hoangngk and everyone on this thread: #6056 has just been merged. Feel free to checkout master, build and test that new feature. Any feedback / bug reports will be really appreciated before we release it.

@totalcloud-tc
Copy link

totalcloud-tc commented May 7, 2020

hi, can I create this chart on X-axis with the above feature, @simonbrunel
any reference link is appreciated:)

Screenshot from 2020-05-07 11-19-41

@benmccann
Copy link
Contributor

You can make a horizontal chart: https://www.chartjs.org/samples/latest/charts/bar/horizontal.html

If you don't want space between you can make it a stacked chart: https://www.chartjs.org/samples/latest/charts/bar/stacked.html

If you do want space between, then yes you'll need this floating bar feature

@flaushi
Copy link

flaushi commented May 8, 2020

...or create the spaces yourself like 52 - (5) - 177 - (5) - 58 where the bracketed spacers have transparent color.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests