Oxql page heatmaps - #3349
Open
fakemonster wants to merge 6 commits into
Open
Conversation
We're in an odd state now; non-oxql pages pass their loading/error/empty responsibilities down to the chart, but when there's an unknown number of charts to render, we need to handle that responsibility up in the caller.
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
I was doing it wrong and also I don't have to.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The base oxql-page PR lacks support for distributions. That's because they're complicated! This PR adds that support.
Primarily, this adds a new
Heatmapcomponent, which renders an empty uPlot chart, and then draws the actual heatmap on top of it. Doing so involves extracting a great deal of content from TimeSeriesChart, so we're going to have some fun conflicts with the design PR, but the extraction itself involved little refactoring, so it should mostly be "copying over those changes".