-
Notifications
You must be signed in to change notification settings - Fork 19
Scaling utilization Y axis #1772
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
Conversation
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
app/components/TimeSeriesChart.tsx
Outdated
| // We use the largest data point +20% for the graph scale | ||
| // clamping at `maxValue` (if set) which is usually overall capacity | ||
| const calculatedMaxValue = useMemo(() => { | ||
| if (!maxValue) return null |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Don't you still want a reasonable max on the chart (like dataMax * 1.2) if none is specified from outside? Or it just does it for you?
app/components/TimeSeriesChart.tsx
Outdated
| if (!maxValue) return null | ||
| if (!rawData) return maxValue | ||
| const dataMax = Math.max(...rawData.map((datum) => datum.value)) | ||
| const unroundedValue = Math.min(maxValue, dataMax * 1.2) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As long as we don't have the capacity number nailed down, I'm wary of picking maxValue as the max if dataMax is actually bigger. In the unfortunate case where dataMax is bigger than maxValue, we have to set the chart max to at least dataMax, otherwise you're not seeing all the data. Ideally in that situation we would also show a dotted flat line or something at maxValue too, though that can be a separate change. We'd have to explain it somehow too.
I came up with this after banging my head against this for bit. Does it make any sense?
| Situation | Exact range | Desired max |
|---|---|---|
| Data way less than cap | dataMax * 1.2 < maxValue |
dataMax * 1.2 |
| Data close to cap but still under | dataMax < maxValue < dataMax * 1.2 |
maxValue |
| Data over cap (pathological but possible) | maxValue < dataMax |
dataMax * 1.2 |
The middle one is the odd one out. I think that's what's messing me up. What if we always used dataMax * 1.2 as the top edge of the chart, and then if maxValue happens to be inside the range of the chart, we show it as a dotted line? Or maybe not always dataMax * 1.2 — maybe if dataMax is anywhere near maxValue, like at least half of it, we make the max of the chart big enough that the maxValue line is shown.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That sounds about right for me. Setting the top of the graph to the capacity doesn't really clearly communicate that if it's not being applied regardless of usage. So some other indicator is probably best.
Whilst the max capacity is still fuzzy, we could probably just omit it and the logic around keeping the maxValue line visible. Happy to just change to dataMax * 1.2 for now.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think that would work. We'd scrap maxValue altogether in that case, right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For now yeah, we can revisit when we have updated capacity values. Looks like we can use Recharts reference lines when thats ready: https://recharts.org/en-US/examples/LineChartWithReferenceLines
| } | ||
| : { | ||
| tickSize: 6, | ||
| } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I got rid of tickSize here — I thought it was weird to only specify it when there's a max, but also 6 is the default anyway so we're not doing anything.
oxidecomputer/console@0cc1e03...9940fd0 * [9940fd0d](oxidecomputer/console@9940fd0d) oxidecomputer/console#1790 * [d07ca142](oxidecomputer/console@d07ca142) oxidecomputer/console#1784 * [0a32ccf8](oxidecomputer/console@0a32ccf8) oxidecomputer/console#1787 * [e74d5aec](oxidecomputer/console@e74d5aec) oxidecomputer/console#1772 * [a68c7c86](oxidecomputer/console@a68c7c86) oxidecomputer/console#1779 * [b2b3a748](oxidecomputer/console@b2b3a748) oxidecomputer/console#1774 * [0f015505](oxidecomputer/console@0f015505) bump playwright for UI mode improvements * [1ccff371](oxidecomputer/console@1ccff371) oxidecomputer/console#1582
oxidecomputer/console@0cc1e03...9940fd0 * [9940fd0d](oxidecomputer/console@9940fd0d) oxidecomputer/console#1790 * [d07ca142](oxidecomputer/console@d07ca142) oxidecomputer/console#1784 * [0a32ccf8](oxidecomputer/console@0a32ccf8) oxidecomputer/console#1787 * [e74d5aec](oxidecomputer/console@e74d5aec) oxidecomputer/console#1772 * [a68c7c86](oxidecomputer/console@a68c7c86) oxidecomputer/console#1779 * [b2b3a748](oxidecomputer/console@b2b3a748) oxidecomputer/console#1774 * [0f015505](oxidecomputer/console@0f015505) bump playwright for UI mode improvements * [1ccff371](oxidecomputer/console@1ccff371) oxidecomputer/console#1582
Fixes #1640
There's a few small changes in here.
maxValue(if set) which is usually overall capacitycalculatedMaxValueto be divisible by 6 so we get even ticksOn the
maxValuerounding – we could do it the other way round where we find a number of ticks that fits but it might be confusing to have it change between graphs. The uneven tick lines was most obvious on disk space because we are using TiB.