Elasticsearch: Add custom query variable editor

[marefr]

What this PR does / why we need it:
I never remembers the syntax for Elasticsearch template variable queries so decided to have a look at adding a custom query variable editor for Elasticsearch.

Fields:

Terms:

Which issue(s) this PR fixes:
None at the moment, but maybe should create one?

Special notes for your reviewer:
What's or thoughts regarding snapshot testing? Was unsure so added it for all new components.

[torkelo]

Looks good! the use of the blue "query-keyword" form labels feels a bit off as none of the other form labels use it

Think we (soon) need to add TemplateVariables[] input prop to the QueryEditor interface and have more shared code / utils to create selects that have template variables so that not every editor needs to fetch them from templateSrv and construct the option list.

There is https://github.com/grafana/grafana/blob/master/public/app/core/components/Select/MetricSelect.tsx

that is a start that Erik did that Stackdriver is using, maybe that can be used here?

[marefr]

GitHub misses to send notifications sometimes 😢 Had missed your review completely.

the use of the blue "query-keyword" form labels feels a bit off as none of the other form labels use it

Stackdriver query editor uses that that's why, but I'm glad to remove that?

Think we (soon) need to add TemplateVariables[] input prop to the QueryEditor interface and have more shared code / utils to create selects that have template variables so that not every editor needs to fetch them from templateSrv and construct the option list.

Yeah that's probably a good idea.

There is https://github.com/grafana/grafana/blob/master/public/app/core/components/Select/MetricSelect.tsx

that is a start that Erik did that Stackdriver is using, maybe that can be used here?

I looked at the MetricSelect but didn't think that was searchable and supported. Gonna have another look at that.

[torkelo]

So question is if we should switch to object model now for the variable query instead of a string like stackdriver is using. Would require migration or handling both string and query object in the data source.

The VariableQueryProps interface looks strange, onChange(query: any, definition: string)

and template editor stores a definition prop on the query variable persistence object that is not used anywhere. Think this is s remnant from a previous design idea from Erik where there was a query or a definition object but looks not be used anywhere.

[marefr]

So question is if we should switch to object model now for the variable query instead of a string like stackdriver is using. Would require migration or handling both string and query object in the data source.

Not sure I follow. Are you talking about that variable queries is stored in dashboard model as a json string? Tried to store it as object for Elasticsearch but something treats it as string somewhere do didn't work. That's why I've still store it as json string.

The VariableQueryProps interface looks strange, onChange(query: any, definition: string)

and template editor stores a definition prop on the query variable persistence object that is not used anywhere. Think this is s remnant from a previous design idea from Erik where there was a query or a definition object but looks not be used anywhere.

It's used to render the definition here:

[torkelo]

The definition string still feels a bit strange like persisting a view model in the dashboard json.

What expects the Elasticsearch template variable query to be a string? Beside the elasticsearch metricFindQuery ?

[torkelo]

But I think we can merge this and improve it later. Would be nice to have the query be an object model and not a string now we have this but we could do that later as well.

[marefr]

Planning to look into what exactly the issue is with using an object model before merging this.

[stale]

This pull request has been automatically marked as stale because it has not had activity in the last 2 weeks. It will be closed in 30 days if no further activity occurs. Please feel free to give a status update now, ping for review, or re-open when it's ready. Thank you for your contributions!

[stale]

This pull request has been automatically closed because it has not had activity in the last 30 days. Please feel free to give a status update now, ping for review, or re-open when it's ready. Thank you for your contributions!

[stale]

This pull request has been automatically marked as stale because it has not had activity in the last 2 weeks. It will be closed in 30 days if no further activity occurs. Please feel free to give a status update now, ping for review, or re-open when it's ready. Thank you for your contributions!

[marefr]

Planning to pick this up

[stale]

This pull request has been automatically marked as stale because it has not had activity in the last 2 weeks. It will be closed in 30 days if no further activity occurs. Please feel free to give a status update now, ping for review, or re-open when it's ready. Thank you for your contributions!

[marefr]

Planning to pick this up

[stale]

This pull request has been automatically marked as stale because it has not had activity in the last 2 weeks. It will be closed in 30 days if no further activity occurs. Please feel free to give a status update now, ping for review, or re-open when it's ready. Thank you for your contributions!

[stale]

This pull request has been automatically closed because it has not had activity in the last 30 days. Please feel free to give a status update now, ping for review, or re-open when it's ready. Thank you for your contributions!