feat(dashboards): Auto-size Big Number widget

[gggritso]

Before:

After:

Bonus:

Explanation

The "Big Number" widget is a Dashboards feature where a user can make a query like count() and get a big honkin' number that shows how many transactions they have. The widget has some fancy CSS to help size it big (but not too big), but CSS alone isn't enough. In many cases, the big number gets truncated! That's not very nice or very useful.

This PR changes the approach. Instead of CSS, it adds a new utility component called AutoSizedText. This component mimics the height and width of its parent, and then iteratively updates the font size of its contents until they fit nicely inside the parent. e.g.,

• The parent is 300px by 300x, and contains the text "OH HELLO"
• The component splits the difference and renders the text at a font size of 110px ((200px + 20px) / 2). It sets the known bounds to 20px minimum and 200px maximum
• The component determines the child is too big because it has bigger dimensions than its parent. It splits the difference between the current and minimum font size, and sets it to 165px ((110px + 200px) / 2). It updates the known bounds to 20px minimum and 200px maximum (since 200px is known to be too big) and renders again
• The child is still too big. The component narrows the font size search field again (note: this works kind of like a binary search) by splitting the difference between the current and minimum font size ((165 + 20) / 2) to 92.5. It updates the known bounds to minimum 20px and maximum 165px.
• This process continues until the child is either within 5% of the parent dimensions and fits inside the parent or it runs out of calculations (maximum of 5 per component)

Other Methods Considered

1. SVG. SVGs can auto-scale to a parent, and can contain <text> elements. I didn't like this approach because font scaling by percentage is not at all the same as changing the font size. Modern typefaces do a lot of work to look legible at different sizes at the font level, and the only way to respect this is to set the correct font size
2. CSS transform has the same problem as SVG scaling
3. Container Queries. This doesn't work because container queries make it easier to set the font size as a proportion of the container, but our case is very complicated. For one thing, we'd need to clamp and scale on both width and height, but the width of the content is fully variable based on which characters are used. There's no known ratio that would work. For another, that approach doesn't work at all for multi-line text? Etc.
4. Canvas. There's a way (I hear) to render text to a canvas and use measureText to get the dimensions, but that's fairly complicated

FAQs

I think the most obvious question is what's the performance like. In short, it's not great, but I did what I could. The most important thing is wrapping the updates in useTransition which will mark them as lower priority. This will allow other, higher-priority renders (like interactions with other dropdowns) to interrupt the resizing logic. I also limited the iteration count to 5, and debounced the resize listener. This seems to work well enough even with CPU throttling set pretty high.

Overall I'm not too worried because resizing is not a common operation, and it's still pretty fast compared to how long a Dashboard resize already takes (a long time).

The second is testing. Short of literal snapshots (which I don't think we do anymore) I couldn't come up with anything that felt more worthwhile than manual QA. You tell me, though.

Fixes #75730

[narsaynorath]

Just a comment around the error-ish condition where we reach the maximum depth. I think we should be tracking something here so we can look back and see if there are issues, otherwise it's failing silently. This looks great, I owe you a hot chocolate 😁

[edwardgou-sentry]

Pretty cool solution! Thanks George!

[gggritso]

@edwardgou-sentry @narsaynorath @JonasBa thanks for the reviews! I made some major changes to the component, so I'm re-requesting the review and marking comments as stale, since so much has changed!

@narsaynorath I added instrumentation! I was going to, I swear, you caught me being lazy. The condition you asked about doesn't exist anymore, so I'm just logging the iteration count
@edwardgou-sentry the code changed a lot, and I'm not calculating disparity ratios anymore, much simpler to just use pixel thresholds

@JonasBa I've addressed, I think a lot of your concerns, thank you for those suggestions:

1. No more React state at all, everything is kept in refs
2. Only one resize observer, and only one ref to keep track of the child
3. The iteration runs in a loop and blocks the UI thread to prevent jitters
4. Fewer props and simpler logic! No need to set min and max anymore
5. No more parent mimic component

I did keep some of the old stuff:

• useLayoutEffect is still there. I like it too much. It's a handy way to express side effects and cleanup, and I do like to re-mount when the iteration parameter changes. Thoughts?

The overall approach is still the same. I also updated the docs, while I was at it, and added more inline code comments.

Thank you for your reviews, please look again when you have a chance 🙏🏻

[JonasBa]

If I were to use a component like this, this isnt something I'd want to have to think about. I think we should remove it, and revisit the component design if this ever becomes a requirement

[gggritso]

🤔 I guess that makes sense but you don't have to think about it, it's optional! I immediately thought that I'd want to change this if I use this in a component where fitment is important (e.g., in a headline or some other important visual element)

[JonasBa]

How would you go about guiding folks to set a good value here? What I'm afraid of is that everyone would just set it to 0 because they'd want it to be the exact size (which is kind of the goal already?)

[gggritso]

I think that's okay, actually! In fact, maybe what I should do is set the default to 0 (or 1px just to be safe) and set it to 5px just in Dashboards where there might be many of these numbers and I don't wanna halt the UI thread too long. Thoughts?

[JonasBa]

How would you evaluate if that is a good config? Does that mean we'd need to care about how many big numbers we render and update this over time?

[gggritso]

🤔 okay let me see how much the iteration count actually affects the render time on pages with a lot of big numbers. If it's low, I will set the tolerance to 1px and remove the prop

[gggritso]

Alright! Sold! Removed it, and added a note about iteration counts and performance related to the threshold 👍🏻

[JonasBa]

🏅 for comments like these

[JonasBa]

Nice work @gggritso, I think you found a cleaner implementation that is less opinionated than before with the code being easier to follow!

[JonasBa]

Thoughts on trimming or rounding the floating point values here? I dont think this is an issue tbh, but it might generate some really long floats here :D

[gggritso]

I could! Ostensibly modern fonts handle sub-pixel rendering gracefully enough. Are you worried about DOM bloat?

[JonasBa]

I think the browsers will handle it fine (though different platforms render text quite differently). I think its more likely just going to be an instance where someone inevitably sees a high precision float in the DOM and starts asking around or making up some wrong ideas, which is a conversation you can spare yourself from having :D

[JonasBa]

Really nice work, A+ for implementation, stories and code comments!