-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
feat: hogql editor pane #14688
feat: hogql editor pane #14688
Conversation
Had to check it out, even if it's draft! 👍 I noticed the second "refresh" button behind the "..." as the black tooltip alerted me to it. However we already have the other "reload" button that's part of the data table. These data table queries can be as hard as insight queries, so I'm wondering what can be done. My take is that as something geared towards power users, I'd like to be able to reload my sql query when I choose to, or I'll just start fudging around with This PR makes it a bit better - we can now cancel queries if we want to abort the refresh - but ultimately I guess in "edit mode" we should hide the top level refresh from the sql table view. |
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.
Loving it, and found some things:
-
Now that the refresh button is gone, there's no way to cancel the running query. I'd still advocate for bringing it back. All removing it does is make people write stupid queries like this:
-
When running SQL queries on top of a data warehouse, you're usually dealing with queries that finish in several seconds to several minutes. Having some way to actually know the query running time is very very useful. I'd use it to adjust the sampling factor for example to make sure all results come back in a reasonable amount of time when I'm exploring.
-
Instead of the "Q", could we use the pancakes on both icons?
- Could this say "SQL" instead?
-
Can we hide this additional "Query" tab for now.... and stick something like a
<BetaTag />
behind "SQL"? I'd like data tables as insights, but let's scope it down and release one thing at a time. The UX with the "query" tab as it is now seems rather confusing... -
Also left one comment inline about how to pass the context...
isOnInsightPage(context) ? null : showReload ? canLoadNewData ? <AutoLoad /> : <Reload /> : null, | ||
isOnInsightPage(context) ? null : showElapsedTime ? <ElapsedTime /> : 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.
I think the logic is upside down here. Think of the "frontend/src/queries" folder as a self-contained library.... and everything under "frontend/src/scenes" as "the posthog app".
Other than, yes, some query nodes being called "insight trends node", the data table itself shouldn't care about the context it's being called on. It shouldn't know or care that such a thing like "an insight page" even exists.
Is there any better way to get the same meaning across? Some things to ponder:
The queries have a bunch of parameters, and similar to the /events
page, you can just add showReload: false
onto new insights if you want to hide just this (I'd still show it thought)... so instead of moving the "if" into the data table, just have it at the scene level.
The less different yes/no state we have, the better. We're going to have a lot of different types of query nodes, and the complexity will skyrocket if there's a "insight mode", "dashboard mode", "full query mode", "inline mode", "superuser mode", etc. If we can have just "view" and "edit", or adding one, just "inline", "view" and "edit" that'd be rather contained.
Right now, a query node with the minimum amount of params opens the "inline" view (e.g. {kind: 'DataTableNode', source: {kind:'EventsNode'}}
). Adding "full:true" opens the edit view. There's no "view" mode.
Should we swap full: true
to mode: 'inline' | 'view' | 'edit'
or should this even be a separate parameter to the <Query />
tag, not as part of the query itself?... 🤔
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.
Wasn't expecting #14709 to grow so much...
I was worried about the amount of showX
this has and didn't want to add more. But this is just a showX
but with a different name.
Happy to switch it out... we can follow up by reducing the number of things you can toggle if need be
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.
If I'm not hiding the reload button then I don't need to pass that context in at all.
I think separately we need to make sure we can measure performance of these queries in the time-to-see data and then decide if we want to hide the reload button for the same reasons as with insights. But don't need to resolve that right now IMHO
Ah, the joy of language merging with Friday brain... By "hide the top level refresh" you didn't mean the reload button 🤣
Ah, no, I was wrong on both counts. I'll get #14709 in and then I know what the fix is.
Yep, I'm using the query tab as a debug place much like the query page... I guess the query page should move entirely to the query tab eventually. Since I use it so much I'll stick another feature flag so we can toggle things to our hearts' content |
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.
Had a look again, a test is failing, and found two other things to say 🙊. Also still the isOnInsightPage(context)
question is an open one 🤔
@mariusandra ok, I think this is mergeable.. although needs follow-up like #14709 have set it so the query tab only shows for staff users until we know we either don't need that tab or are happy with the flow. |
📸 UI snapshots have been updated1 snapshot changes in total. 0 added, 1 modified, 0 deleted:
Triggered by this commit. |
📸 UI snapshots have been updated1 snapshot changes in total. 0 added, 1 modified, 0 deleted:
Triggered by this commit. |
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.
frontend/src/queries/schema.ts
Outdated
@@ -240,6 +241,7 @@ export interface DataTableNode extends Node { | |||
hiddenColumns?: HogQLExpression[] | |||
/** Show with most visual options enabled. Used in scenes. */ | |||
full?: boolean | |||
|
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.
Gonna block everything for this space now. :police_hog:
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'd guess the loading weirdness is some inconsistency with coordinating filters and queries state which is getting a bit tangly now. But will take a look...
* feat: hogql editor pane * schema build * type fix * hide reload in insight placement * push the query tab for just staff users (while things are in flux) * user can be null * remove Q * put insight query tab behind a flag * fix loading from drop down: requires #14709 * less is more * quick and dirty show correct editor panel until #14709 is in * don't hide the reload button * copy url change in from #14709 to fix new insight dropdown in this PR * add beta tag to tab label * only show query tab to posthog staff * Update UI snapshots for `chromium` (2) * Update UI snapshots for `chromium` (2) * fix things missed while rushing 🙈 * slightly better viewbox * don't show SQL as an option in new insights if the feature flag isn't on * very important change --------- Co-authored-by: github-actions <41898282+github-actions[bot]@users.noreply.github.com>
Problem
We want an hogql editor pane
Changes
readonly
props from query and query contextadds ahideInlineEditorButton
context since on insight views the query is editable but that button should be hiddenplacement
to the context since the query chrome varies in some circumstancesIt's not done done, but I'm going to stack on top of this since there are a few loosely related changes and it'll get to be a huge PR - see #13927
How did you test this code?
👀 locally