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

[discreteBarChart] Fix y axis ticks number calculation. #2105

Merged
merged 2 commits into from
Mar 1, 2018

Conversation

ovvn
Copy link
Contributor

@ovvn ovvn commented Sep 27, 2017

Fixes #2104

@zheoreh
Copy link

zheoreh commented Sep 28, 2017

+1

6 similar comments
@fctsvirus
Copy link

+1

@majvik
Copy link

majvik commented Sep 28, 2017

+1

@DeWenS
Copy link

DeWenS commented Sep 28, 2017

+1

@Yska
Copy link

Yska commented Sep 28, 2017

+1

@astranomus
Copy link

+1

@diesel457
Copy link

+1

@jeznag
Copy link
Contributor

jeznag commented Oct 16, 2017

Seems like unit tests would be a good idea given large changes to calcTicksY function.

Also why the nv.log calls?

src/utils.js Outdated
maxValue = values[j] && values[j][yAccessor] ? values[j][yAccessor]: 0;
numValues = maxValue > numValues ? maxValue : numValues;
}
}
Copy link
Contributor

Choose a reason for hiding this comment

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

This seems super inefficient... so this is looking at every node on the chart? Surely there is a better way to chose a tick count...

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Let's see. Incoming data for the discreteBarChart always has the following format:

[
  {
    "values": [
      {
        "label": "Label1",
        "value": 3,
        "series": 0
      },
      {
        "label": "Label2",
        "value": 123,
        "series": 0
      },
      {
        "label": "Label3",
        "value": 777,
        "series": 0
      },
        ...
    ]
  }
]

So complexity would be O(n) where n = data[0].values.length. The linear complexity is obviously efficient and very fast.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Just to clarify, the idea behind this pull request is to calculate y axis ticks for the discrete bar chart based on y values, not on x values as it is now https://jsfiddle.net/ovvn/g5qwwthx/1/embedded/result/. We've been using the fix for half a year on production and it works great for us.

Copy link
Contributor

Choose a reason for hiding this comment

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

Yes, it's O(n), but for very large (millions) of points n is still sufficiently big to potentially cause problems in a browser. And that's not just worst case, it's every time because you always have to traverse the entire array. I see you're thinking about a simple bar chart, but this function is used by more than just that... if you want to override the function to calculate the tick count just for one type of chart, then I'd keep all the logic in the chart itself.

Also, what's the difference between getY and yAccessor options? Seems like that's overlapping functionality?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Traversal in an array with millions of items is not a problem. What can be a problem is appending millions of elements into a browser's DOM, but that has nothing to do with the pull request. The functionality is not made for just one type of chart, it's generic and can be extended for other types as well. The difference between getY and yAccessor is that getY is a function and yAccessor is a string (y value property name). But that's a good point, don't remember why I made the property name to be passed explicitly. Think we can reuse the getY fn.

@liquidpele
Copy link
Contributor

This appears to use the same logic as this PR, so linking them: #2028

@@ -15,6 +15,7 @@ nv.models.discreteBar = function() {
, y = d3.scale.linear()
, getX = function(d) { return d.x }
, getY = function(d) { return d.y }
, yAccessor
Copy link
Contributor

Choose a reason for hiding this comment

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

Seems like yAccessor should replace getY

src/utils.js Outdated
*/
nv.utils.calcTicksY = function(numTicks, data, yAccessor) {
if (yAccessor) {
// find max number of values from all data streams
Copy link
Contributor

Choose a reason for hiding this comment

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

If I'm not mistaken, this comment doesn't reflect what the code does. It doesn't find the max number of values, it finds the maximum y value in the entire dataset.

@liquidpele liquidpele merged commit 4bb381d into novus:master Mar 1, 2018
*/
nv.utils.calcTicksY = function(numTicks, data, getY) {
if (getY) {
// find max number of values from all data streams
Copy link
Contributor

Choose a reason for hiding this comment

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

This comment is incorrect

// currently uses the same logic but we can adjust here if needed later
returns number of ticks to actually use on Y axis, based on chart data
*/
nv.utils.calcTicksY = function(numTicks, data, getY) {
Copy link
Contributor

Choose a reason for hiding this comment

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

There should be unit tests for this function

if (getY) {
// find max number of values from all data streams
var numValues = 1;
for (var i=0; i < data.length; i += 1) {
Copy link
Contributor

Choose a reason for hiding this comment

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

This code fails linting guidelines

numValues = maxValue > numValues ? maxValue : numValues;
}
}
nv.log("Requested number of ticks: ", numTicks);
Copy link
Contributor

Choose a reason for hiding this comment

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

Debugging code should be removed

@jeznag
Copy link
Contributor

jeznag commented Mar 1, 2018

@liquidpele @ovvn I don't feel that this code was ready to be merged for the following reasons

  1. It has no unit tests
  2. The code is not formatted according to the NVD3 eslint config (https://github.com/novus/nvd3/blob/master/.eslintrc.json)
  3. I don't think it has been tested on mobile phones with large datasets. The algorithm may perform poorly on low power CPUs. Should be tested with CPU throttling.
  4. The comments in the code are misleading
  5. The debugging code should be removed

I have left line comments in the PR pointing out these issues. Would be great to see a follow up commit from @ovvn addressing these points.

@liquidpele
Copy link
Contributor

@jeznag yea, I may have been a little too lenient on that one.

@ovvn can you take care of the concerns brought up?

@ovvn
Copy link
Contributor Author

ovvn commented Mar 2, 2018

@jeznag

  1. Yes, having unit tests is a good idea.
  2. Yes, the indentation wasn't right.
  3. When you say "large", what numbers are you talking about? You might need to read more about javascript performance and algorithm difficulty but in this particular case it will work fine regardless of cpu power. Do you have an experience working with d3 visualisations on desktop and mobile?
  4. Yes, there was 1 outdated comment.
  5. Don't see why the debugging code should be removed. The code is present in the 'calcTicksX' as well.

@ovvn
Copy link
Contributor Author

ovvn commented Mar 2, 2018

@liquidpele
Yes, fixed some issues in the pull request #2144.
I think unit tests for all util helpers is a good idea for future pull requests.

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

Successfully merging this pull request may close these issues.

None yet

10 participants