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

[NumericInput] Support arbitrary precision inferred from smallest step size #833

Merged
merged 13 commits into from
Mar 14, 2017

Conversation

cmslewis
Copy link
Contributor

Fixes one sub-issue in #607

Checklist

  • Include tests

Changes proposed in this pull request:

Currently, the most granular NumericInput step size of any kind (minor/major/regular) is 0.1. This PR adds support for arbitrarily small step sizes, adjusting the max precision of the displayed value accordingly (similar in intent to #832). As before, the precision of the displayed value shows the minimum number of decimal places necessary for each value (i.e. 1 displays as "1", not "1.000").

Reviewers should focus on:

  • I copied @giladgray's implemention of countDecimalPlaces from Slider labelPrecision #832, will reuse his exact implementation here once that PR merges.
  • The toMaxPrecision code feels a little wonky. There's probably a simpler way. Thoughts?

@giladgray
Copy link
Contributor

@cmslewis i just merged #832 👍

}

private toMaxPrecision(value: number) {
let { stepMaxPrecision } = this.state;
Copy link
Contributor

Choose a reason for hiding this comment

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

const

const { stepMaxPrecision } = this.state;
// round the value to have the specified maximum precision (toFixed is the wrong choice,
// because it would show trailing zeros in the decimal part out to the specified precision)
return +(Math.round(parseFloat(value + "e+" + stepMaxPrecision)) + "e-" + stepMaxPrecision);
Copy link
Contributor

Choose a reason for hiding this comment

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

using parseFloat and + in the same sentence, nice. how about parseFloat twice though, for clarity?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Ah, yep, makes sense.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Done

@blueprint-bot
Copy link

Fix lint (use const instead of let)

Preview: docs
Coverage: core | datetime

@blueprint-bot
Copy link

Use parseFloat instead of +, add source link

Preview: docs
Coverage: core | datetime

const { stepMaxPrecision } = this.state;
// round the value to have the specified maximum precision (toFixed is the wrong choice,
// because it would show trailing zeros in the decimal part out to the specified precision)
// source: http://stackoverflow.com/a/18358056/5199574
Copy link
Contributor

Choose a reason for hiding this comment

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

👍 thanks!

stepMaxPrecision = Math.max(stepMaxPrecision, Utils.countDecimalPlaces(props.minorStepSize));
}

return stepMaxPrecision;
Copy link
Contributor

Choose a reason for hiding this comment

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

what if you did like:

if (minorStepSize) { return countDecimalPlaces(minorStepSize); }
else { return countDecimalPlaces(stepSize); }

then we only count maximum once. and the minorStepSize should be the smallest one, right? so we can just go off that.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Sweet, I like that better. 👍 This was a relic from a few commits ago, when I considered adding a configurable precision prop that we'd have to sanitize.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Done

// round the value to have the specified maximum precision (toFixed is the wrong choice,
// because it would show trailing zeros in the decimal part out to the specified precision)
// source: http://stackoverflow.com/a/18358056/5199574
return parseFloat(Math.round(parseFloat(value + "e+" + stepMaxPrecision)) + "e-" + stepMaxPrecision);
Copy link
Contributor

Choose a reason for hiding this comment

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

this math is frightening and possibly expensive, but i get it. also the experience is sweet as the precision adjusts automatically.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Voila: https://jsperf.com/roundtomaxprecision. Will tweak this line based on these findings.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Done

Copy link
Contributor

Choose a reason for hiding this comment

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

um wow
jsperf

@blueprint-bot
Copy link

Respond to CR feedback, eliminate unnecessary basic-example props

Preview: docs
Coverage: core | datetime

}

private toMaxPrecision(value: number) {
const { stepMaxPrecision } = this.state;
// round the value to have the specified maximum precision (toFixed is the wrong choice,
// because it would show trailing zeros in the decimal part out to the specified precision)
// source: http://stackoverflow.com/a/18358056/5199574
Copy link
Contributor

Choose a reason for hiding this comment

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

update this source link? points to old code

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 left it because it still captures the original idea, even though I made syntactic changes. Should I just remove it?

@cmslewis cmslewis merged commit 7b1fa6e into master Mar 14, 2017
@cmslewis cmslewis deleted the cl/numeric-input-precision branch March 14, 2017 09:05
@giladgray giladgray mentioned this pull request Mar 14, 2017
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