React UI: Implement more sophisticated autocomplete #6160

juliusv · 2019-10-17T14:20:48Z

It would be great to have more sophisticated expression field autocompletion in the new React UI.

Currently it only autocompletes metric names, and only when the expression field doesn't contain any other sub-expressions yet.

Things that would be nice to autocomplete:

metric names anywhere within an expression
label names
label values
function names
etc.

For autocomplete functionality not to annoy users, it needs to be as highly performant, correct, and unobtrusive as possible. Grafana does many things right here already, but they also have a few really annoying bugs, like inserting closing parentheses in incorrect locations of an expression.

Currently @slrtbtfs has indicated interest in building a language-server-based autocomplete implementation.

slrtbtfs · 2019-10-17T14:36:55Z

I'm currently in the process of building that language server. It lives at https://github.com/slrtbtfs/promql-lsp.

The features you named are all intended to land there. Support for completing metric and function names will probably be implemented in the coming two weeks.

Other features include:

Showing syntax error messages while typing (done)
Showing documentation and type signatures on hover (in progress)
PromQL Syntax highlighting (not part of the language server, but exists already)

The part that has to be done on the React UI side to support the language server would be to provide a language client. A good candidate for that seems to be the monaco editor which is also used by vscode and is surprisingly fast and responsive when included in a web UI (See https://microsoft.github.io/monaco-editor/playground.html).

cc @squat

juliusv · 2019-10-17T14:39:35Z

@slrtbtfs Wonderful! Really looking forward to this :) Do you know if you'll have capacity to work on the React UI integration as well?

slrtbtfs · 2019-10-17T15:02:32Z

It would make sense to do so. Especially as there probably is a lot of overlap with the PromQL vscode extension (https://github.com/slrtbtfs/vscode-prometheus).

I'll discuss this with my managers.

juliusv · 2019-10-20T10:20:32Z

@slrtbtfs One point to consider: Monaco is not exactly small. Even just the minified editor.main.js is >2MB large. That doesn't make me immediately rule it out, but if we could do what we need with a significantly smaller download size, that would be much better of course.

slrtbtfs · 2019-10-21T11:58:48Z

@juliusv Progress on the language server side is tracked here https://github.com/slrtbtfs/promql-lsp/issues?utf8=%E2%9C%93&q=+is%3Aissue+label%3A%22React+UI%22+

Edit: And here: https://github.com/slrtbtfs/promql-lsp/blob/master/doc/progress.md

slrtbtfs · 2019-10-25T12:09:29Z

@juliusv An possible alternative might be the CodeMirror editor (400kb unminified, 250kb minified). Someone has started building a language client for that one: https://github.com/wylieconlon/lsp-editor-adapter .

Although the development of the lsp client seems to have stalled, it already supports the features we need for our use case, according to https://langserver.org/ .

It also looks small enough that we can fix issues with it ourself, if needed.

Edit: Add minfied size

juliusv · 2019-10-25T16:30:27Z

Ah cool, 250kb is getting into the realm of being less painful (although it's still quite big, I guess for what we want to do, that's a reasonable size).

boyskila · 2019-10-25T20:35:47Z

As per https://bundlephobia.com/result?p=codemirror@5.49.2 is even less - 165kb minified

Nexucis · 2019-11-11T12:30:09Z

Hi,

With my collegue @celian-garcia, we made a library to provide PromQL in Monaco. It is quite closed to the one provided in Grafana. Recently I presented it to @juliusv and he asked me if we implemented a real PromQL parser/grammar.

So no, we didn't and on my point of view I don't think it's really worth it to implement it on the client side. Autocompletion and syntax highlight should be enough, at least for the Prometheus Console.
Implementing a new parser in Typescript would say to maintain two different parser in two different language.
The only advantage I will see with that is: You can know in real time that you have an error in your PromQL query. (same way you have it in a IDE)

Concerning this library, we'll try to provide the PromQL language as a native language in Monaco, we are waiting a response from Microsoft about how you can make the autocompletion when it is a native language. (It's not super crystal clear for us :)) (microsoft/monaco-editor#1672)

Depending of what LSP can provide in the Json, but I'm thinking that we could make a similar configuration in CodeMirror (same way we did for Monaco).
And it maybe make sense to do it in a different repository (like prometheus/react-promQL-lsp), so it can be used in other UI/IDE if they want to integrate the Prometheus Console.

@juliusv I hope I didn't forget any particular point and thanks for your patient :)

slrtbtfs · 2019-11-11T13:06:55Z

@Nexucis

Hi,

good to know you've been working on a similar thing.

Recently I presented it to @juliusv and he asked me if we implemented a real PromQL parser/grammar.
So no, we didn't and on my point of view I don't think it's really worth it to implement it on the client side.
Implementing a new parser in Typescript would say to maintain two different parser in two different language.

One advantage of using the language server protocol is, that the language server can be written in any language. In this case it is written in go and uses the same parser as prometheus.

Depending of what LSP can provide in the Json, but I'm thinking that we could make a similar configuration in CodeMirror (same way we did for Monaco).

Not having to implement the same features multiple times for different editors is actually the point of the language server protocol. The LSP allows implementing these features once and then using them with basically any editor, including vim, emacs, monaco, codemirror, eclipse, ...

Autocompletion and syntax highlight should be enough, at least for the Prometheus Console.

Completion and syntax highlighting are not the only useful features one can provide for language support. Consider e.g. showing errors and documentation. See e.g. https://imgur.com/a/Lwv8G2e

Also note that Completion is far less trivial than it looks at first.

Completion for metric names and labels only works, if it is known what timeseries reside on the server
When completing function arguments, the completer should be aware of the type signatures of the respective functions
When completing label names the completer should be able to figure out, which labels occur together with the given metric name
Context sensitive completion on this level only works, when the query is actually parsed, to figure out the necessary metadata.

Another important point to consider is, that PromQL queries often occur as part of yaml files. For a useful editor integration this case should be supported, too. The PromQL language server already does this.

juliusv · 2019-11-11T14:06:43Z

Thanks for the input, both of you!

@slrtbtfs That makes sense for the case of complex autocompletion at least, yeah. Just curious, do LSP clients cache certain completion information in a way that e.g. function / operator names can be autocompleted without constant roundtrips to the server, or does basically every keystroke lead to an LSP request?

For syntax highlighting, it seems there's no LSP support for it yet (microsoft/language-server-protocol#682 (comment)), and it is is generally considered to be better done on the client-side (for speed / reliability reasons anyway)? So I guess the syntax highlighting portion of what @Nexucis did here would be applicable for client-side UI integration (if ported to whatever editor we choose to use)?

slrtbtfs · 2019-11-11T14:34:07Z

Just curious, do LSP clients cache certain completion information in a way that e.g. function / operator names can be autocompleted without constant roundtrips to the server, or does basically every keystroke lead to an LSP request?

Usually there is a limit how many completions the server offers for a single request (by default 100). If the returned list is complete, i.e. there are less than 100 available completions, the server can tell this to the client and the client won't ask for additional completions again

For syntax highlighting, it seems there's no LSP support for it yet (microsoft/language-server-protocol#682 (comment)), and it is is generally considered to be better done on the client-side (for speed / reliability reasons anyway)?

Yes, that would be reusable. I've actually already done something similar for the vscode extension for prometheus, too. The main difference seems to be that @Nexucis provides the syntax highlighting using some typescript and I use a textmate grammar.

The advantage of the textmate grammar is, that it can be used by some other tools than vscode, e.g. eclipse and atom. The advantage of the typescript approach is, that it might allow slightly better highlighting.

slrtbtfs · 2019-11-11T14:37:40Z

Just curious, do LSP clients cache certain completion information in a way that e.g. function / operator names can be autocompleted without constant roundtrips to the server, or does basically every keystroke lead to an LSP request?

The server can additionally tell the client to only ask for completions, if the cursor is over a word separator. This way no completions will be asked for if the cursor is somewhere in the middle of a word.

juliusv · 2019-11-11T16:09:29Z

Thanks for the background! So I guess for completion we will just wait for server-side LSP support then, but need to decide what to do for highlighting in the meantime. That in turn seems gated on the editor decision. If anyone interested wants to give CodeMirror a deeper look in terms of usability, quality, and LSP support (for our use case), that seems like the next step.

Nexucis · 2019-11-11T16:50:04Z

Thanks for your feedback about the LSP feature @slrtbtfs . Futur is bright with it :).
On our side we will try CodeMirror, we are also interested to reduce the footprint of Monaco.
I think we'll begin just by make the migration from Monaco to CodeMirror without LSP.
Then once it is done, we'll try with LSP if nobody else has done it.

slrtbtfs · 2019-11-11T17:08:33Z

@Nexucis Sounds good, especially since I'm not that good with front end stuff.

In case it is useful, here is a TextMate grammar for PromQL. At least for VS-Code it needs to be converted to JSON before using it.

The language server isn't able to talk over a network, yet. I'll fix this soon, to make experiments with Code Mirror possible.

celian-garcia · 2019-11-11T17:33:25Z

Thank you @slrtbtfs @juliusv for all the inputs ! I'm sure it will help us ;)
FYI, we also found this. https://github.com/codemirror/CodeMirror/pull/4948/files
It's pretty outdated but maybe it's worth it to throw an eye.

We'll keep you informed ;)

slrtbtfs · 2019-11-13T17:45:48Z

@juliusv @celian-garcia @Nexucis

The language server is now in a state where you can try it out locally. It even has some limited support for auto completion.

Support for remote clients is not yet there, however.

https://github.com/slrtbtfs/promql-lsp

Nexucis · 2019-11-13T19:28:33Z

@slrtbtfs uuuh so cool ! Thanks. On my side, I didn't advance so much on the topic unfortunately :(. The promCon gave me many things to think and to say to my team :).

brian-brazil · 2019-12-10T13:42:52Z

Some aspects of a typical LSP implementation have become apparent that are a problem for Prometheus.

Firstly communication is typically done via JSON-RPC over WebSocket, which is not at all like our current APIs.

Secondly the LSP needs to maintain state for each active client (https://microsoft.github.io/language-server-protocol/overview) of at least the document (query) it's working on. This is both a complexity and reliability risk.

I think any such functionality and communication needs to happen internal to the frontend, and any communication to the Prometheus server itself is done via our standard APIs.

slrtbtfs · 2019-12-10T14:12:01Z

I think any such functionality and communication needs to happen internal to the frontend.

The idea of having a language server is kind of the opposite of having it in the frontend.

While I agree with some of the concerns, there are actually good reasons to not implement such features on the client side:

Every client has to implement these features for itself. Right now we already have different completion implementations for Prometheus, Thanos and Grafana which leads to a lot of duplicate effort. Also each of these only implements a very limited feature set.
Having the language server written in golang allows to use the same parser as Prometheus. This allows having much more insights into queries than existing tools.

Secondly the LSP needs to maintain state for each active client (https://microsoft.github.io/language-server-protocol/overview) of at least the document (query) it's working on. This is both a complexity and reliability risk.

For more complex setups like Thanos or Grafana it would be also possible to run the language server in a sidecar container which might reduce these risks.

brian-brazil · 2019-12-10T14:23:40Z

The idea of having a language server is kind of the opposite of having it in the frontend.

That's fine when it's running on a developer's desktop or dedicated SaaS. Not when it's living inside a key process of a critical monitoring system.

Having the language server written in golang allows to use the same parser as Prometheus.

I'm not worried about the parser, I'm worried about the other parts. Namely the architecture that implicitly comes with an LSP.

For more complex setups like Thanos or Grafana it would be also possible to run the language server in a sidecar container which might reduce these risks.

I don't think that solves the problem. I'm proposing to sidestep the problem by having the usual LSP client<-> server communication happen entirely inside the browser when it's a Prometheus type use case where the primary purpose of the binary in question is monitoring.

slrtbtfs · 2019-12-10T14:25:12Z

Creating a stateless API that uses the same logic as the PromQL language server is something that should be actually possible from a implementation side.

I have some doubts about whether it's a good idea though, since that would essentially mean creating a new protocol.

Nexucis · 2020-03-08T11:46:55Z

Hello guys :)
Just wanted to tell you that I started the promQL mode for CodeMirror here
I'm quite satisfied with the syntax highlighting ( I put a screenshot in the readme so you can judge by yourself )
I'm a bit struggling with the autocompletion. But I guess it's just matter of time.
Otherwise, I'm wondering if I should put this library immediately somewhere in a neutrale zone (like prometheus community). Any thought @juliusv ?

And regarding the "lsp" integration I'm thinking that maybe it will be nice if the CodeMirror mode has a "offline" mode. Like that people that cannot have access to a Prometheus (like for example because of Cross Origin issue) can still have a PromQL editor.

Do you think it will be interesting ?

juliusv · 2020-03-09T18:16:40Z

@Nexucis

Just wanted to tell you that I started the promQL mode for CodeMirror here

Nice!

Otherwise, I'm wondering if I should put this library immediately somewhere in a neutrale zone (like prometheus community).

I would like that. Will raise it with the others.

And regarding the "lsp" integration I'm thinking that maybe it will be nice if the CodeMirror mode has a "offline" mode.

Yeah, definitely LSP-based autocompletion needs to be optional for cases where you don't use it directly from a Prometheus server.

slrtbtfs · 2020-03-09T18:22:55Z

Yeah, definitely LSP-based autocompletion needs to be optional for cases where you don't use it directly from a Prometheus server.

The PromQL language server and the PromQL language server REST API both can work without a Prometheus server to get data from. Syntax error checks, function name completion and function documentation still work in that case.

The main issue here is that some host to run the language server would be required.

Alternatively it should be also possible to run the language server in a browser using Web Assembly. However that would require downloading the langserver wasm binary, which is about 4mb gzipped.

juliusv · 2020-03-09T18:30:08Z

The PromQL language server and the PromQL language server REST API both can work without a Prometheus server to get data from. Syntax error checks, function name completion and function documentation still work in that case.

Good to know! I think in the normal Prometheus server we can always require the full backend support, as the Prometheus UI needs to be able to reach its API anyway. But editors might then use just the language server without a Prometheus server. Not sure if there's a good-enough use case for even pulling the language server itself into the UI using wasm (especially at 4MB size).

Nexucis · 2020-03-09T19:01:43Z

it can be "ok" if you still have access to internet I guess, which is not always the case.
But let's see how far we can go in the offline mode ^^

slrtbtfs · 2020-03-09T19:10:58Z

It might be that tinygo will be able to compile the language server somewhen in the future, which might significantly reduce binary sizes.

Nexucis · 2020-04-05T15:36:01Z

Hello Guys,
I hope you are all ok during this period.
I have some news regarding the light library I started few weeks ago :)

So just after saying I was finished the syntax highlight, I thought it would be nice for the "offline" mode to highlight when the syntax is not good.
After couple of times of intense coding and failure, I finally decided to move to the proper way: which is having a grammar.

So now I have a light grammar of promQL and I'm able to hightlight some error. Not all of them are hightlighted but it's a start (and the error shown is super ugly). I also have the autocompletion ready :)

Here some kind of error that are not covered :

100 > 100 --> doesn't return an error. I did it on purpose and not sure it will be easy to make it better
100>my_tric --> it's not parsed. The parser is waiting a space to analyze it
100 > group_left 15 ---> doesn't return an error. Same problem as 100 > 100. Grammar too subversive
1 - 100 ) --> doesn't return an error. A bit weird, no idea why

You can try it by yourself using this playground: https://nexucis.github.io/codemirror-mode-promql/
I hope you will like this new way to handle the syntax hightlighting, the autocompletion and the beginning of the error highlightning.

cheers!

PS: @juliusv any news regarding if I should put it in a neutral zone ?

Nexucis · 2020-04-05T22:31:32Z

Oh and by the way the light grammar I wrote is compatible with Prism (thanks to this lib). So if Grafana is still using it like it is mentionned in this blog post and is interesting by it, it would be possible to share it with them

juliusv · 2020-04-06T10:04:06Z

@Nexucis Thanks, doing well, hope you're ok too!

Oh wow, interesting! Are the current limitations of your client-side error display ones that run into fundamental problems with the CodeMirror grammar support, or is it just not "done" yet? Would be really cool to get 100% reliable client-side syntax error markings of course! Btw. not sure if you were aware of it, but we changed PromQL back to a generated parser (from a custom-built one), so now this file basically has the full grammar definition for the language: https://github.com/prometheus/prometheus/blob/master/promql/parser/generated_parser.y

PS: @juliusv any news regarding if I should put it in a neutral zone ?

I just filed prometheus-community/community#19 and prometheus-community/community#20. I had previously asked on Chat, but I think it got ignored, so thanks for reminding me.

Nexucis · 2020-04-06T10:32:24Z

@juliusv I'm ok too :) thanks !

I saw the yacc file and actually I was searching for a lib that would generate the typescript/javascript code thanks to the yacc file. But I didn't find it :(.

Regarding the current limitations, I'm not sure.
My fundamental issue so far is to be able to say to the parseur :

100 * 100 is a scalar
100 * my_metric is a vector

Because last time I was trying it, the 2nd rule didn't work because it said to me it expects a scalar.
So for the moment I factorize the two rules in a single one, which is the main cause of the current limitation.
Maybe if I'm taking a deep dive into the yacc file I will find how to solve it. I guess in the beginning of the promQL grammar you maybe had a similar issue.

But I'm agree with you, it would be super cool to cover 100% of all possible syntax.

Finally regarding the ugly error the codeMirror is currently returning when you are writting a wrong expression, I think it is just I don't handle all functionalities provided by the lib codeMirror-grammar

I just filed prometheus-community/community#19 and prometheus-community/community#20. I had previously asked on Chat, but I think it got ignored, so thanks for reminding me.

Oh cool, thanks a lot !

juliusv · 2020-04-06T10:46:39Z

@Nexucis So in Prometheus the grammar itself initially allows any expression type (vector/matrix/string/scalar) around binary operators (

prometheus/promql/parser/generated_parser.y

Lines 228 to 244 in 44ad28d

    
           // Operator precedence only works if each of those is listed separately. 
        
           binary_expr     : expr ADD     bin_modifier expr { $$ = yylex.(*parser).newBinaryExpression($1, $2, $3, $4) } 
        
                           | expr DIV     bin_modifier expr { $$ = yylex.(*parser).newBinaryExpression($1, $2, $3, $4) } 
        
                           | expr EQL     bin_modifier expr { $$ = yylex.(*parser).newBinaryExpression($1, $2, $3, $4) } 
        
                           | expr GTE     bin_modifier expr { $$ = yylex.(*parser).newBinaryExpression($1, $2, $3, $4) } 
        
                           | expr GTR     bin_modifier expr { $$ = yylex.(*parser).newBinaryExpression($1, $2, $3, $4) } 
        
                           | expr LAND    bin_modifier expr { $$ = yylex.(*parser).newBinaryExpression($1, $2, $3, $4) } 
        
                           | expr LOR     bin_modifier expr { $$ = yylex.(*parser).newBinaryExpression($1, $2, $3, $4) } 
        
                           | expr LSS     bin_modifier expr { $$ = yylex.(*parser).newBinaryExpression($1, $2, $3, $4) } 
        
                           | expr LTE     bin_modifier expr { $$ = yylex.(*parser).newBinaryExpression($1, $2, $3, $4) } 
        
                           | expr LUNLESS bin_modifier expr { $$ = yylex.(*parser).newBinaryExpression($1, $2, $3, $4) } 
        
                           | expr MOD     bin_modifier expr { $$ = yylex.(*parser).newBinaryExpression($1, $2, $3, $4) } 
        
                           | expr MUL     bin_modifier expr { $$ = yylex.(*parser).newBinaryExpression($1, $2, $3, $4) } 
        
                           | expr NEQ     bin_modifier expr { $$ = yylex.(*parser).newBinaryExpression($1, $2, $3, $4) } 
        
                           | expr POW     bin_modifier expr { $$ = yylex.(*parser).newBinaryExpression($1, $2, $3, $4) } 
        
                           | expr SUB     bin_modifier expr { $$ = yylex.(*parser).newBinaryExpression($1, $2, $3, $4) } 
        
                           ;

), but then only checks the types of the two operands in a separate step after parsing has succeeded:

prometheus/promql/parser/parse.go

Lines 510 to 515 in fac7a4a

    
           if lt != ValueTypeScalar && lt != ValueTypeVector { 
        
           	p.addParseErrf(n.LHS.PositionRange(), "binary expression must contain only scalar and instant vector types") 
        
           } 
        
           if rt != ValueTypeScalar && rt != ValueTypeVector { 
        
           	p.addParseErrf(n.RHS.PositionRange(), "binary expression must contain only scalar and instant vector types") 
        
           }

There are a bunch of post-parsing checks like that that would be infeasible to all do directly in the lexer + parser, so unless we port the entire parser + checker to JS manually it seems infeasible to support all error cases client-side with just a grammar file. But maybe that's fine for a beginning.

Nexucis · 2020-04-06T10:59:12Z

ah ok! Thanks for telling me it. I was wondering if I had forgotten all my knowledge about how to write a grammar because it was so irritating to fail on that :D.

So yes in that case, it won't be feasible to check this kind of error with the current implementation. I just wrote the grammar and I don't have the hand on the lexer + parser. So I cannot intercept the result and analyze it :(.
So I guess for the "offline" mode, it should be enough for the moment. It's already an improvement regarding the monaco editor, so on my side, I'm already quite happy with it :)!

It would be actually super nice to be able to generate the parser and lexer thanks to the yacc file. But that would be an entire but super interesting project by itself.

Nexucis · 2020-05-12T18:32:30Z

Hello,
I finished to build a better development environment, and I will pause a bit the offline mode to be more focus on the "online mode".

Looking at the PR #6872, it seems the functionality needed are not yet ready. Is it something that will be unlocked soon @slrtbtfs ? Do you need some help on it ?
@juliusv do you think, it makes sense to use the promql-langserver directly if functionalities are not yet available in Prometheus ?

slrtbtfs · 2020-05-12T18:48:45Z

Looking at the PR #6872, it seems the functionality needed are not yet ready. Is it something that will be unlocked soon @slrtbtfs ? Do you need some help on it ?

The main blocker currently is prometheus-community/promql-langserver#134 .

I currently don't have the capacity to work on implementing this myself but if someone is willing to work on this, I'll happily help with any questions that arise and review PRs. So help on this would be appreciated.

do you think, it makes sense to use the promql-langserver directly if functionalities are not yet available in Prometheus?

In what context? For using it in VS Code there already exists a VS Code extension. Unfortunately publishing it to the VS Code Marketplace is blocked on prometheus-community/vscode-promql#29 .

Nexucis · 2020-05-12T18:55:58Z

I currently don't have the capacity to work on implementing this myself but if someone is willing to work on this, I'll happily help with any questions that arise and review PRs. So help on this would be appreciated.

Ok I will take a look at it then :).

In what context? For using it in VS Code there already exists a VS Code extension. Unfortunately publishing it to the VS Code Marketplace is blocked on prometheus-community/vscode-promql#29

For using it in codeMirror

slrtbtfs · 2020-05-12T19:12:35Z

For using it in codeMirror

If you're ok with having a language server binary running on some host you can use https://godoc.org/github.com/prometheus-community/promql-langserver/rest . (Using the master branch).

If you're ok with downloading about 5mb of compressed wasm code, you should be able run the language server inside the browser. However this requires a small patch in a dependency.

Ok I will take a look at it then :).

Great!

Nexucis · 2020-05-12T19:56:58Z

Thanks for your answer @slrtbtfs. I think it will depend mainly how much time it will take to finish the PR #6872. And so if I'm able to handle the issue you pointed :).

brancz · 2021-02-18T16:46:57Z

I actually recently implemented an Earley parser for @polarsignals using https://nearley.js.org/

I feel like this might be a better fit than the full-blown language server. Kubernetes SIG instrumentation's promq debugging tool also happens to implement an Earley parser, which should make it somewhat straight forward to convert.

Nexucis · 2021-02-18T17:13:01Z

hello @brancz,

interesting lib indeed :).

I'm sorry for the lack of update on this topic. Actually with @juliusv, we implemented a complete offline parser using lezer+ codemirror v6.

The promql grammar using lezer is available here and the lib that is using it, is available here.

I think codemirror-promql is going to be integrated into Prometheus around Marsh. So quite soon, the Prometheus console will be deeply reviewed :D.

Nexucis · 2021-02-18T17:16:43Z

and also for the followup and maybe for some clarifications. Here is the last conclusion regarding LSP: #6872 (comment)

brancz · 2021-02-19T16:05:19Z

Very cool! Any reason why we haven't integrated this yet?

juliusv · 2021-02-19T16:08:32Z

@brancz My plan is to do it in March!

This adds advanced autocompletion, syntax highlighting, and linting for PromQL. Fixes #6160 Fixes #5421 Signed-off-by: Julius Volz <julius.volz@gmail.com>

juliusv added component/ui kind/feature component/react-ui labels Oct 17, 2019

juliusv mentioned this issue Oct 17, 2019

React UI: Consider re-adding metric name selector #6155

Closed

juliusv mentioned this issue Oct 18, 2019

make expression input controlled #6174

Merged

slrtbtfs mentioned this issue Oct 25, 2019

split autocomplete dropdown in to groups #6211

Merged

slrtbtfs mentioned this issue Nov 2, 2019

Linting support prometheus-community/promql-langserver#48

Open

slrtbtfs mentioned this issue Feb 25, 2020

PromQL langserver api #6872

Closed

3 tasks

slrtbtfs mentioned this issue Mar 15, 2020

Allow clients to connect over websocket prometheus-community/promql-langserver#55

Open

juliusv mentioned this issue Mar 16, 2020

ui: Improve autocompletion #1924

Closed

gouthamve added the priority/P3 label May 25, 2020

Nexucis mentioned this issue Mar 23, 2021

Add new codemirror-promql-based expression editor #8634

Merged

juliusv added a commit that referenced this issue Mar 23, 2021

Add new codemirror-promql-based expression editor

c6f7eb2

This adds advanced autocompletion, syntax highlighting, and linting for PromQL. Fixes #6160 Fixes #5421 Signed-off-by: Julius Volz <julius.volz@gmail.com>

juliusv closed this as completed in faacb61 Mar 23, 2021

prometheus locked as resolved and limited conversation to collaborators Nov 14, 2021

React UI: Implement more sophisticated autocomplete #6160

React UI: Implement more sophisticated autocomplete #6160

Comments

juliusv commented Oct 17, 2019

slrtbtfs commented Oct 17, 2019

juliusv commented Oct 17, 2019

slrtbtfs commented Oct 17, 2019

juliusv commented Oct 20, 2019

slrtbtfs commented Oct 21, 2019 • edited Loading

slrtbtfs commented Oct 25, 2019 • edited Loading

juliusv commented Oct 25, 2019

boyskila commented Oct 25, 2019 • edited Loading

Nexucis commented Nov 11, 2019

slrtbtfs commented Nov 11, 2019

juliusv commented Nov 11, 2019

slrtbtfs commented Nov 11, 2019

slrtbtfs commented Nov 11, 2019

juliusv commented Nov 11, 2019

Nexucis commented Nov 11, 2019

slrtbtfs commented Nov 11, 2019

celian-garcia commented Nov 11, 2019

slrtbtfs commented Nov 13, 2019

Nexucis commented Nov 13, 2019

brian-brazil commented Dec 10, 2019

slrtbtfs commented Dec 10, 2019

brian-brazil commented Dec 10, 2019

slrtbtfs commented Dec 10, 2019

Nexucis commented Mar 8, 2020 • edited Loading

juliusv commented Mar 9, 2020

slrtbtfs commented Mar 9, 2020

juliusv commented Mar 9, 2020 • edited Loading

Nexucis commented Mar 9, 2020

slrtbtfs commented Mar 9, 2020

Nexucis commented Apr 5, 2020 • edited Loading

Nexucis commented Apr 5, 2020 • edited Loading

juliusv commented Apr 6, 2020

Nexucis commented Apr 6, 2020 • edited Loading

juliusv commented Apr 6, 2020

Nexucis commented Apr 6, 2020 • edited Loading

Nexucis commented May 12, 2020

slrtbtfs commented May 12, 2020

Nexucis commented May 12, 2020

slrtbtfs commented May 12, 2020

Nexucis commented May 12, 2020

brancz commented Feb 18, 2021 • edited Loading

Nexucis commented Feb 18, 2021

Nexucis commented Feb 18, 2021

brancz commented Feb 19, 2021

juliusv commented Feb 19, 2021

slrtbtfs commented Oct 21, 2019 •

edited

Loading

slrtbtfs commented Oct 25, 2019 •

edited

Loading

boyskila commented Oct 25, 2019 •

edited

Loading

Nexucis commented Mar 8, 2020 •

edited

Loading

juliusv commented Mar 9, 2020 •

edited

Loading

Nexucis commented Apr 5, 2020 •

edited

Loading

Nexucis commented Apr 5, 2020 •

edited

Loading

Nexucis commented Apr 6, 2020 •

edited

Loading

Nexucis commented Apr 6, 2020 •

edited

Loading

brancz commented Feb 18, 2021 •

edited

Loading