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

Float-bar support. The logic is to use array values [bottomY, topY] i… #5262

Closed
wants to merge 82 commits into from

Conversation

gwyneblaidd
Copy link
Contributor

@gwyneblaidd gwyneblaidd commented Feb 11, 2018

Float-bar support. The logic is to use array values [bottomY, topY] instead of regular vals. SO if you use regular numbers chart will be not floated and bar start will be 0 by default. If you use array for value current update allowing to track this and use bottomY value from array instead of 0.)

Example:
http://pravopys.net/chartjs/samples/charts/bar/vertical.html

…nstead of regular vals. SO if you use regular numbers char will be not floated and bottomY will be 0 by default. If you use array for value current update allowing to track this and use bottomY value from array instead of 0.)
src/core/core.scale.js Outdated Show resolved Hide resolved
@benmccann
Copy link
Contributor

Thanks for this! This will close numerous issues linked to in #4863

docs/charts/bar.md Outdated Show resolved Hide resolved
@gwyneblaidd
Copy link
Contributor Author

Hi @simonbrunel, @etimberg!

This pull request for adding floating bar support. Can you check pls, so maybe it should be upgraded/changed.

This should fix #4863 issue.

@simonbrunel
Copy link
Member

I think it's a good start, I need to review it more deeply, but don't have time right now. I agree with the data format [min, max] (as suggested in #4863), but we need to be sure we are picking the right one because if it's merged, we can't change it until next major version.

We also need to be sure that:

  • it works with horizontal bars
  • it works with stacked bars

A few early feedback:

  • instead of duplicating the logic to pick the "right" value in each scale, it may be better to move it directly in getRightValue()? Though, that would need some investigation to be sure it doesn't break anything.
  • I would not introduce the new borderSkipped: 'none' value, but instead support borderSkipped: false|null.
  • I would not call it lowY or highY but low/hight or min/max
  • we will need unit tests

A few early feedback:

instead of duplicating the logic to pick the "right" value in each scale, it may be better to move it directly in getRightValue()? Though, that would need some investigation to be sure it doesn't break anything.
I would not introduce the new borderSkipped: 'none' value, but instead support borderSkipped: false|null.
I would not call it lowY or highY but low/hight or min/max
@gwyneblaidd
Copy link
Contributor Author

gwyneblaidd commented Feb 24, 2018

Hi @simonbrunel @benmccann !

I have made changes according to your suggestions.

I have tested all chars, so here the links for you to test it also:

vertical char with linear scale
http://pravopys.net/chartjs/samples/charts/bar/vertical.html
vertical char with log scale
http://pravopys.net/chartjs/samples/charts/bar/vertical-log.html
vertical-stacked char with linear scale
http://pravopys.net/chartjs/samples/charts/bar/stacked-vertical.html
vertical-stacked char with log scale
http://pravopys.net/chartjs/samples/charts/bar/stacked-vertical-log.html

horizontal char with linear scale
http://pravopys.net/chartjs/samples/charts/bar/horizontal.html
horizontal char with log scale
http://pravopys.net/chartjs/samples/charts/bar/horizontal-log.html
horizontal -stacked char with linear scale
http://pravopys.net/chartjs/samples/charts/bar/stacked-horizontal.html
horizontal -stacked char with log scale
http://pravopys.net/chartjs/samples/charts/bar/stacked-horizontal-log.html

@simonbrunel
Copy link
Member

There are multiple approaches to handle {min, max} stacked bars:

  • a. ignore stacking (which seems the solution adopted in this PR )
  • b. stack height only (start at 0):
    • bar(0).y0 = 0
    • bar(0).y1 = bar(0).max - bar(0).min
    • bar(n).y0 = bar(n-1).y1
    • bar(n).y1 = bar(n).y0 + (bar(n).max - bar(n).min)
  • c. stack height (start at bar(0).min):
    • bar(0).y0 = bar(0).min
    • bar(n).y0 = bar(n-1).y1
    • bar(n).y1 = bar(n).y0 + (bar(n).max - bar(n).min)
  • d. stack from origin:
    • bar(0).y0 = bar(0).min
    • bar(n).y0 = bar(n-1).y1 + bar(n).min
    • bar(n).y1 = bar(n).y0 + (bar(n).max - bar(n).min)

a. can be achieved without stacking
b. can be achieved by stacking number data
c. implies no gap between bars but doesn't necessary start at origin
d. implies gap between bars

I don't think a. is correct because it's not "stacked" but then I'm not sure between b, c and d. Maybe d. is the best behavior (that's what @etimberg suggested in #4863) because it allows to implement c. as well by mixing {x, y} and number data.

@benmccann
Copy link
Contributor

@gwyneblaidd the rebase seems not to have worked. It looks like most of your changes disappeared

@gwyneblaidd
Copy link
Contributor Author

@gwyneblaidd the rebase seems not to have worked. It looks like most of your changes disappeared

yepp, i had problems with rebasing, everytime smth was in conflict, i had to create new pull request to this one to replace all files so now this pull request has no changes regarding to original repo. But i will return back today all my changes with new commits.

@@ -124,11 +124,11 @@ var supportsEventListenerOptions = (function() {
// https://github.com/chartjs/Chart.js/issues/4287
var eventListenerOptions = supportsEventListenerOptions ? {passive: true} : false;

function addEventListener(node, type, listener) {
function addListener(node, type, listener) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure why cbb7ff7 is showing up on this PR. Seems the rebase didn't totally work

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

when i has all that failing tests i thought that smth really bad went with merge last time. So, i downloaded lates Chart.js files, replaced with it all my local files and commited to my fork. So, in this case my repo should look like the current Chart.js version. So, all that changes came when i replaced files. I have put back my changes again on float-bat support after. Are thise chanages on this file are not correct?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i have replaced all files from current chart.js version. Is this file is not correct?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i think because this was commited only 2 days ago thats why i picked it

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The changes shouldn't appear on your PR. The problem is that your PR is comparing to a version of the code from a few days ago probably instead of to the latest master. You should run git rebase master again (and maybe make a backup copy first before doing that)

It's probably really hard to rebase with 82 commits spanning a year on the PR. It's possible you might have an easier time opening a new PR at this point rather than rebasing

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

... or you can squash all your 82 commits in a single one, and rebase it on top of master. Then we can keep working in the same PR with all previous comments.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@gwyneblaidd if you need help squashing / rebasing this PR, please join our Slack #dev channel. But please don't open a new PR with these 82 commits, it will be useless.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Forget my comment about squashing commits, I didn't realize you already merged many times our master into your branch, which makes the operation quite complicated, so it would be easier to start a new PR from scratch.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

rebased PR - #6056

@simonbrunel simonbrunel closed this Feb 8, 2019
@royduin
Copy link

royduin commented Feb 8, 2019

Just for reference, new PR: #6056

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

Successfully merging this pull request may close these issues.

None yet

9 participants