[FEATURE]: Add Quick Query Viewer

[shahrokni]

Closes #3071

Description 🖊️

This is the Quick Query Viewer kick-off .

⚠️ More interesting ideas can be added later on top. Let's have a scaffold first ...

Test 🧪

1. Open a project
2. Then go to a dashboard
3. All panel headers should have an extra functionality (Query Viewer)
4. Click on the icon button
5. Do you see the queries? (It should show all quires)
6. You can also open Tree View

Screenshots 🖼️

Checklist

• Pull request has a descriptive title and context useful to a reviewer.
• Pull request title follows the [<catalog_entry>] <commit message> naming convention using one of the
  following catalog_entry values: FEATURE, ENHANCEMENT, BUGFIX, BREAKINGCHANGE, DOC,IGNORE.
• All commits have DCO signoffs.

UI Changes

• Changes that impact the UI include screenshots and/or screencasts of the relevant changes.
• Code follows the UI guidelines.
• Visual tests are stable and unlikely to be flaky.
  See e2e docs for more details. Common issues include:
  • Is the data inconsistent? You need to mock API requests.
  • Does the time change? You need to use consistent time values or mock time utilities.
  • Does it have loading states? You need to wait for loading to complete.

[jgbernalp]

This probably should be inside the overflow menu, we have a lot of actions and they are included in a menu for smaller screens

[shahrokni]

This probably should be inside the overflow menu, we have a lot of actions and they are included in a menu for smaller screens

Sorry, I did not get the point,
It is already in the OverFlowMenu. Are you suggesting, it should be removed from here?

[jgbernalp]

It is not, it should be inside <OverflowMenu>

[andreasgerstmayr]

If you go to the "Node Explorer" dashboard, and hover over the "Sys Load (5m avg)" panel, it looks like this in Chrome:

(this is a "medium panel width" panel). Moving it to <OverflowMenu> should fix it.

[jgbernalp]

@shahrokni awesome, this is definitely useful but I see we are reusing the plugin spec editor, and passing a no op when changing values to make it read only. The problem I see is with UX, users would think they can adjust the query here and change values like the datasource, legend, etc. But nothing will happen, and it might be considered an error. Should we at least have an attribute to mark the plugin editor as readonly? this will allow plugin developers to disable/hide controls when using a readonly mode.

[andreasgerstmayr]

Two UI improvements to consider:

• the modal dialog should be consistent with the other dialogs in Perses (e.g. "add panel group" dialog): it should have a title and the buttons on the bottom should be outlined
• I'd add some visual separation between the queries (either a horizontal line or collapsing functionality)

Otherwise, LGTM :)

[shahrokni]

@shahrokni awesome, this is definitely useful but I see we are reusing the plugin spec editor, and passing a no op when changing values to make it read only. The problem I see is with UX, users would think they can adjust the query here and change values like the datasource, legend, etc. But nothing will happen, and it might be considered an error. Should we at least have an attribute to mark the plugin editor as readonly? this will allow plugin developers to disable/hide controls when using a readonly mode.

Indeed this is misleading. That is my concern too. The point is that there is a isReadOnly field which doesn't disable the controls. I think, since this component is used in Edit Forms, and in Edit forms you can change the query and see results quickly (without saving), the flag doesn't disable the controls but simply disable the Save Button. (Or something like that)

To resolve this issue, if I am not mistaken, we need to change some stuff around plugins first. Because, PluginSpecEditor is only a wrapper on top of the

const { data: plugin, isLoading, error } = usePlugin(pluginType, pluginKind);
/* Some code here*/
 const { OptionsEditorComponent } = plugin;
  return OptionsEditorComponent ? <OptionsEditorComponent {...others} /> : null;

If you allow me we resolve this matter, first with a separate PR for plugins, and then again we get back here and add some improvements.

[jgbernalp]

sure if there is a property already available, then is responsibility of the plugin to do it. Thnx for the clarification