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

Adding a new option to make the y-axis fixed. #888

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

saboya
Copy link

@saboya saboya commented Nov 23, 2017

While I do realize this is unlikely to be accepted, I'd like to bring up this discussion and maybe someone proposes a better solution.

On Dygraphs 1.x, when you zoomed out the graph with a double click, the y-axis was preserved. On Dygraphs 2.x, the y-axis automatically set based on the data. There's an example about this here:

https://github.com/danvk/dygraphs/blob/aa0b189f8cb22d64ce65cc9b205c90f6e4fd1257/tests/old-yrange-behavior.html

The same example also shows how you can get around the new behavior using a plugin for the double-click event. However, when using the rangeSelector plugin, there doesn't seem to be an easy way around this.

It should be possible to restore the valueRange property on the predraw event, however, since using updateOptions triggers a redraw, it has to be done without it, thus becoming error-prone. However, after further investigation, I couldn't find a way to do this with animatedZooms: true, since the animation is calculated using newValueRanges = this.yAxisExtremes();.

Finally. I also think this behavior is undesired if a valueRange was explicitly set. Dygraphs doesn't offer a way to change the y-axis by default, so it's impossible to restore the initial graph state without resorting to custom code. which I find very counter-intuitive.

I did not write an auto_test for this, but am willing to if this PR is to be accepted in its current form, or any form that leads to a solution to the problem.

Feedback is appreciated. Thanks for your hard work.

@coveralls
Copy link

Coverage Status

Coverage decreased (-0.03%) to 90.138% when pulling 4b25a70 on saboya:fixed-y-axis into 64f1c4d on danvk:master.

@squaregoldfish
Copy link
Contributor

Is there a case for having a similar option for the x axis?

@saboya
Copy link
Author

saboya commented Nov 24, 2017

I can't think of a use case for a fixed x axis, and dygraphs gives you tools to manipulate the x axis, contrary to the y axis.

@saboya
Copy link
Author

saboya commented Nov 28, 2017

With a bit more knowledge of Dygraphs inner workings, I managed to work around the issue without a modified version of Dygraphs using a plugin to override the getExtremeYValues function of the dataHandler on every predraw (and removing yRangePad).

export class FixedYAxis {
  activate (dygraph) {
    const valueRange = dygraph.getOption('valueRange')

    if (!valueRange) {
      throw new Error('No valueRange set')
    }

    const getExtremeYValues = () => valueRange
    const predraw = (e) => (e.dygraph.dataHandler_.getExtremeYValues = getExtremeYValues)

    // Default value of 0.1 will add 10% Y-axis padding
    dygraph.updateOptions({ yRangePad: 0 }, true)

    // Must override dataHandler.getExtremeYValues every predraw
    return { predraw }
  }
}

FixedYAxis.toString = () => {
  return 'FixedYAxis Plugin'
}

However I consider this a very complex solution to something that should be very simple, and I don't know what possible side-effects the getExtremeYValues override might cause.

Anyway, hopefully this is useful to someone.

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

Successfully merging this pull request may close these issues.

None yet

3 participants