Oxql page - #3312
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
|
Idea: |
This also makes some design decisions unilaterally, such as a rotating color palette, and legends/what they look like.
I'm not entirely sure this is what we're going to love. As you drag the mouse around, the alpha changes are quite noisy. I wonder if we can get by with just highlighting the active point (instead of _all_ the points on that X) and stick the color itself in the tooltip? The other thought I'm having here: in the legend, there's not much to do other than throw all the legend values in line like that (or come up with aliases, but then you need some sort of hover). Within a tooltip, though, this could be actually formatted!
Maybe we'll actually hang on to something like this in the long run, but for now it's just plain handy.
MSW already supports a few specific queries, and we could expand that support, but the challenge is less in adding more metrics/targets, and more in needing increasingly rich parsing of queries to determine what the query is actually asking for (multiple tables, alignments, joins, groupings). For now, I think our bases are covered by just guaranteeing it always returns _something._
Writing the query to the url is ugly, BUT it lets people bookmark! This change also adds functionality for disabling the loading bar, because by default it would begin _after_ successful queries (since I'm electing to only write queries that succeeded to the URL), which just looked weird.
uPlot is fast, but it's not "render 1500 charts at once" fast.
Still contrived, trying to show the different varieties of chart for the sake of review. But at least these are somewhat reasonable examples.
| setTextareaRowCount(getTextareaHeightForQuery(text)) | ||
| form.setValue('query', text) | ||
| }} | ||
| /> |
There was a problem hiding this comment.
I'd make this a dropdown menu button instead of a listbox to avoid giving the impression of a state that syncs with the contents of the textarea. It's just a one-time replace on select, so menu buttons are more appropriate. It would also make it visually smaller.
There was a problem hiding this comment.
to be fair, my intent is to make the query picker, however it's implemented, not feel like an independent input. so it being in sync (like, if you pick a query, delete a paren, and reintroduce it, it re-highlights the query you match) is intentional. but i do like the low profile of the dropdown here. would you imagine it being stateful, meaning you click "Power shelf fan speeds" and that remains visible as you edit, or would you just keep resetting the dropdown state to "Pick an example" instantly?
There was a problem hiding this comment.
I was picturing it like this — no state. To me that fits with the queries being starting points.
There was a problem hiding this comment.
i can vibe with that. let me toy with it (and placement)
There was a problem hiding this comment.
comme ça? i didn't want to toy with encroaching on the vertical space of the textarea itself, but i think kicking this to the right helps suggest it isn't "part of the form" itself. could make a case for putting it below as well
There was a problem hiding this comment.
I think that's fine for now. @benjaminleonard is going to work on it too, so I wouldn't try to get it too perfect. I could see him making some kind of horizontal bar above that has this button in it, etc. Anything is possible.
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 `Heatmap` component, 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". --------- Co-authored-by: benjaminleonard <benji@oxide.computer>
…3355) I'd been meaning to do this for a while. Nearly all the changes are to the tests. ### 🤖 summary The unit suite is now pure logic running in node; anything that touches the DOM is a vitest browser mode test. That lets us remove jsdom, `@testing-library/*`, and msw/node entirely, along with the unit setup file, whose three stubs (canvas, matchMedia, ResizeObserver) existed only to fake DOM APIs jsdom lacks — those tests now run against the real things. The non-mechanical bits: * The API client tests run against an MSW worker in the browser (the same mechanism the dev server uses) instead of msw/node's patched fetch. * `TimeSeriesChart` created a canvas at module scope, which made it un-importable without a DOM — this is what the setup file's canvas stub was for. The measuring context is now created lazily. * The `TimeSeriesChart` spec no longer mocks anything: it renders real uPlot and spies on the instance's `redraw`/`setData` via a test-only `onCreate` prop. An earlier version of this PR kept the jsdom-era `vi.mock` of uplot-react, which flaked on webkit in CI — with a cold dep optimizer cache, the mock can attach to a different copy of the module than the one under test. Instance spying is the fallback because uPlot assigns its methods per instance; there's no prototype to patch. The old data-reference-stability test is reframed behaviorally: rerenders with equivalent data must not call `setData`, changed data must. * The `loginUrl` unit test only exercised string concatenation, so it's replaced with an e2e test covering the actual 401 → `/login?redirect_uri=...` flow, using a new `error-401` sentinel project in the mock API. With that test gone, nothing mocks `nav-to-login` anymore, and mockability was the module's stated reason for existing, so it's folded into `client.ts`. Note for #3312: `TimeSeriesChart.spec.tsx` moved to `TimeSeriesChart.browser.spec.tsx` and was rewritten around real uPlot instance spies, so the spec edits there will need porting.
2 participants
Keeping in draft for a moment, because we may not want to merge this as-is, but this is a basic loop of "send a query, show it". There's the open design question of "do we prefer a builder form", which should be easier to discuss live. I'm also more than open to input on where we want to take the mock service worker for this. As-is it works just fine, but the OxQL results space is much wider than what the MSW is configured to deliver. You basically have to point at real data to see the fully variety of visualizations.