You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Would it be possible to display the errors in the playground in the "Compiled SQL" tab instead of the footer?
Having the errors in the "Compiled SQL" tab would allow using the "Copy to clipboard" link/button which would make it a bit easier for bug reports.
It also keeps the user's focus in one place because you're already watching there for your output. If you're typing in the playground and hit an error at some point, it's not clear what version of the input the Compiled SQL represents. I think it would be better if that area had the error output (or was cleared on errors) so you don't mistake that SQL for corresponding to the current PRQL (which is broken) in case you didn't notice the error message.
I've also had cases where the error message was too long and took over the whole window and I couldn't recover access to the PRQL input area anymore and had to reload the whole page (losing my work). I think that particular issue may have been fixed already though.
The text was updated successfully, but these errors were encountered:
One issue with having the error there is that the output is flickering while we're typing. If we're in the middle of a transform, I think we often still want to see the most recently valid output:
from invoices
derive
I agree we could have some sort of visual indicator on the result tab, such as a small red icon. And a copy button on the error pane...
Having the errors in the "Compiled SQL" tab would allow using the "Copy to clipboard" link/button which would make it a bit easier for bug reports.
This looks more UX friendly.
One issue with having the error there is that the output is flickering while we're typing.
We can debounce the parsing/transforming logic with something like lodash.debounce, which is common for these kind of scenarios. Instead of recalculating on every keystroke, we can wait for the user to stop typing, let us say 2 seconds which will prevent the flickering issue.
If people pause typing when they have a valid query, then debouncing may make sense, since we're not going to show errors when people are mid-typing.
But my sense is that people pause for lots of reasons; often when there's no valid query, and having the prior valid query is still helpful. I'm not confident in this and if others feel strongly, we could adjust.
One downside with debouncing is that the compiler then feels much less responsive, and it's really nice to have responsive output. We can add complications, such as only debouncing when the compiler returns an error, though at the cost of more complications.
What's the objection to just making it clear in some other way that the current query isn't valid, like a red icon? We could even gray the whole query (seems too strong but less strong that removing the whole result...)
Again, I'm not super confident, so if someone has a strong view and wants to make the change, I will accept it if it looks reasonable.
What's up?
Would it be possible to display the errors in the playground in the "Compiled SQL" tab instead of the footer?
Having the errors in the "Compiled SQL" tab would allow using the "Copy to clipboard" link/button which would make it a bit easier for bug reports.
It also keeps the user's focus in one place because you're already watching there for your output. If you're typing in the playground and hit an error at some point, it's not clear what version of the input the Compiled SQL represents. I think it would be better if that area had the error output (or was cleared on errors) so you don't mistake that SQL for corresponding to the current PRQL (which is broken) in case you didn't notice the error message.
I've also had cases where the error message was too long and took over the whole window and I couldn't recover access to the PRQL input area anymore and had to reload the whole page (losing my work). I think that particular issue may have been fixed already though.
The text was updated successfully, but these errors were encountered: