Console warnings for IntTimesPowerOfTenFormatter

[bcolloran]

On e.g. this page, we're seeing warnings about the usage of IntTimesPowerOfTenFormatter, such as:
received invalid input for IntTimesPowerOfTenFormatter: 120

In this example, this occurs because an axis has a value of "120%":

There was a request from product+design at some point that we restrict axis labels to a single digit integer times a power of ten, which works well in the general case once you include small numbers and huge numbers and negative numbers and dollar signs etc -- so to minimize clutter in axis labels, one digit of precision was the call.

We can change that, but the risk is a proliferation of special cases -- e.g. maybe 2 digits is fine for %s that happen to fall in say 0%-200%, but if you are already out of the range of proper fractions from 0-100%, there is nothing to say that in you might not encounter thousands of percent etc, in which case a single digit is likely preferable again.

WRT the IntTimesPowerOfTenFormatter: it is designed to accept a single digit integer times a power of ten -- it's somewhat robust, so, as we can see in this example it formats its input without any problems. But it's only tested to provide correct formatting when it's assumptions are met. In particular, I suspect it would return incorrectly formatted numbers in the case of small fractions. And this is why the warning is there: to let us know that we're passing in an unexpected value and that we may hit unexpected behavior

So there are a few ways we can proceed at this point:

• just turn off the console warning.
  • Pro: This is a one line change, and the formatter does the right thing in most cases today
  • Con: it's not fully tested, and may produce bad formats in rare cases
• use one digit in most cases, but add special cases for certain ranges of numbers or number types where we want to allow multiple digits to pass through to the axis.
  • Pro: fine grained control, and also minimal cluttter in the general case
  • Con: gets complicated fast, hard to set the ranges well, lots of edge cases, probably a lot of work to get right
• specify a new digit limit for the general case -- always allow 2 digits or 3 digits for example
  • Pro: pretty straight forward to implement, and the d3 tick function that we use upstream often returns ticks with one digit of precision anyway
  • Con: less concise and clean looking in the general case

@nishantmonu51 @djbarnwal @ericpgreen2 : please chime in with your preferences! Once we make a call, I'll do the fix

[bcolloran]

bump @nishantmonu51 , fyi @mindspank

[ericpgreen2]

Thanks for spelling this out, Brendan. IMO silencing the console warning is a fine quick-fix for now. Given we haven't had anyone report issues with our axes labels recently (AFAIK), the formatter must be doing a good job in most cases. As long as you keep the warning in the code, then we'll still be able to trace the problem if we ever do have customer complaints.