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

API or documentation for scale nicing #40

Open
fin opened this issue Jul 20, 2015 · 9 comments
Open

API or documentation for scale nicing #40

fin opened this issue Jul 20, 2015 · 9 comments

Comments

@fin
Copy link

fin commented Jul 20, 2015

The fix to #32 disabled auto-nicing. The (undocumented) way of nicing scales I found is:

chart.using('lineSeries', function(line) {
  line.beforeRender(function(chart) {
    this.y.nice();
  });
});

I'd appreciate if this could be done declaratively, like setting the Key for the Axis.
Should I take the time to implement this and send a pull request, or should I just add the workaround to the documentation?

@heavysixer
Copy link
Owner

Hey @fin absolutely, if you have a way of making d4 better which doesn't break anything in terms of backward compatibility I am all for it. My feeling is that this should probably be an accessor, there are several examples of how to do this in other features. Also you will probably want to checkout https://github.com/heavysixer/d4-www to run your changes against the examples directory. If you have both projects checked out side by side it's designed to copy over your development version of d4 into the example site so that you can ensure you are not breaking anything.

Thanks again for the interest in D4

@fin
Copy link
Author

fin commented Aug 24, 2015

hey,
i have tried to build this and now i'm confused. it looks like the .domain() calls in builders/scales.js is always d3.scale.domain, not the anonymous functions d3.scale.domain is wrapped with by base.js/createAxisScaleAccessor

do you have a minute to shed some light on this?
thanks.

@heavysixer
Copy link
Owner

Hi @fin is there a branch i can pull to see what's going on? I think i'll need to be able to reproduce the error before i can help.

@fin
Copy link
Author

fin commented Aug 25, 2015

i pushed a clean commit, the diff to your master will be slightly more involved since grunt seems to re-format sourcefiles as well, but those are the only functional changes:

fin@eed88c7

figured it would be enough to override the proxy's .domain function to call .nice after its values were set, but the proxy seems to not be accessed by the builders.
which means my mental model for what's going on was wrong. i'll try to look further into it, but if you have pointers i'd appreciate them!

@heavysixer
Copy link
Owner

@fin awesome, let me pull and see if I can suss out what is going on. Thanks for taking a stab at it.

@heavysixer
Copy link
Owner

working on this now...

@heavysixer
Copy link
Owner

Hey @fin just to make sure I understand what you are after checkout this codepin:
http://codepen.io/heavysixer/pen/wKwBBZ

You'll see you can adjust nice and the chart will update based on the new parameters that are being supplied. This is how d4 works currently without modifications. I am trying to understand where you are trying to use nice() instead.

@fin
Copy link
Author

fin commented Aug 27, 2015

i'm trying to move the .nice into the declaration of the chart.

in your example, the chart is coupled to the data doubly: in the declaration, and through the .datum().call() function.

what i would have wanted to achieve is to have a setting on the axis, saying "should the axis' scale be niced? (y/n/[integer value like d3.time.day])"

so that the chart can be defined independently from the data, and there's only one data ingress point: the .datum().call() pattern.

@heavysixer
Copy link
Owner

Forgive me if I am still not understanding you, but I think we are agreed that we don't want to nice() the entire chart. If you did could do so by pre-processing the incoming data. In my mind nicing lives at the feature level, so that you can nice two axis elements in different ways. The way you'd do that is with the using() pattern (like my example shows). The part I am less clear on is how this approach effects the data ingress point like you pointed out. In my mind, the way nice() works now provides an adequate and desirable separation of concerns between features.

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

No branches or pull requests

2 participants