feat: replace open in query builder with new insight page #14709
Conversation
|
Not sure what's in scope for this PR yet, but I'd expect that clicking the button selects the query tab and closes the drawer. Code wise all looks good 👍 Not for now, just wanted to mention: It would be great to pass the query not by url, but through some router state, which I think isn't possible yet. I suspect we'll run into URL length limit with this otherwise. |
|
I was thinking we should get rid of the drawer altogether. In my imagination the "<>" button on "event explorer" directly opens a new insight. 🤔 Then, I'd hide that button when editing an insight itself. For some views, we could have the "<>" edit query drawer open, but I'd hide that under "..." -> "edit source". |
|
I'm not a fan of the <> either, so +1 for getting rid of that here. Opens up the question of how we'd edit the query for an insight then though. In a previous design decision we opted for making the tabs in insights independent of each other, so that with data exploration each tab will open in a "blank" state. It would be strange if the query tab would behave differently. I could imagine a small toggle in the top-right corner of editor filters that switches from filters to a query view and vice-versa. Edit: Something like this, that's maybe just shown when hovering the editor filters. |
Yep, and at the moment we check "is this an insight viz" and if so you can't get to the query tab! So, we'd deffo need a different route. I like the idea of swapping between text-based editing and click-based editing 🤔 |
|
Summarising this, what about a flow where:
|
|
updated the gif in the description
|
|
Didn't see your comment @mariusandra, so I have a flow
I think that at the moment we need the fall back to "this is a query" and then we can start to open the correct tab as we solidify this The line between an Hmmm, but I did remove the drawer entirely here which gives you no escape hatch for insights 🤔 |
📸 UI snapshots have been updated75 snapshot changes in total. 0 added, 75 modified, 0 deleted:
Triggered by this commit. |
* 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>
|
I think this is very good! I'd ✅ , but Thomas's point might need a look though :/. |
|
@mariusandra current plan here is
then
|
📸 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. |
Problem
Now that the insight scene can be used to edit insights, let's open query editing in a new insight
see #13927
Changes
does that
After #14688 we can teach the insight scene to open the correct tab depending on if a hogql or non-hogql query is being presented
Will follow-up with switching insight viz tabs to text editing...
How did you test this code?
👀 locally