Create a theme / components / guide for using Monaco code editor

[cjcenizal]

From elastic/kibana#14119, per @timroes.

We are currently using react-ace as a code editor with a very tiny wrapper (EuiCodeEditor) implemented in #14026.

This wrapper basically just passes through all properties to react-ace. It would be nice to "build" a code editor (with or without any library) with a proper API where we just expose whatever we need and encapsulate away what we don't need (e.g. custom theming).

This task should be the long running goal for what kind of code editor we want to introduce, what we require and replace the current tiny EuiCodeEditor with that.

---

From @Bargs:

Related elastic/kibana#13621

[snide]

Bringing over content from a @timroes issue in Kibana so we don't have this in two places. I think this is generally on the design team to implement.

elastic/kibana#13645

---

We are currently using Ace as a code editor in several places, e.g.:

• Query Filter UI
• Dev Tools Console
• Time Series Visual Builder Markdown

We use different frameworks (Angular, React) and different initialization mechanisms in these places. Meaning, that we currently have to reimplement the keyboard mode we introduced with #13339 for each of the places.

Also it appears Ace doesn't have the best accessibility in general, looking at some upstream issues:

• Accessibility for screen readers
• Accessibility: Ace traps the Tab key

We should consider how we handle Ace in the long run in Kibana. Should we try to provide upstream fixes for the keyboard interaction (there was even an interesting other suggestion in the ticket above), which would also prevent us from reimplementing it for every framework? Should we switch to a different (more accessible) code editor? Should we just fix the issues upsream to react-ace (that we use in the TSVB) and convert the other places as soon as possible from Angular to React components?

[snide]

There is also a request that the editor should be resizable.

elastic/kibana#6208

[timroes]

Adding to this thread: I think we should replace Ace by Monaco as a short/mid-term solution. It allows a lot of customization, it's very well known by the user and I think even the default design looks more appealing to our overall look and feel than the Ace editor does, that I personally feel looks out of place everywhere in Kibana where it's used.

[snide]

We've thought about it and thought the same. I'd asked the code search team to maybe get it initiated since they are the experts. I'll talk with them next week and see if they can help.

[chandlerprall]

Monaco is very simple to integrate into a project; our code editor isn't very special and it should be easy to replace with Monaco.

Questions:

• Content Security Policy compatibility. Monaco makes XHR requests for the language highlighting stuff and IIRC tries to operate in a web worker.
• How does EUI & its consumers need to interact to support those XHR requests. Ideally this Just Works when webpack does its bundling pass, but need to verify.

[timroes]

I just wanted to raise that issue slightly again. We now use Monaco already in Canvas expression editor and Timelion expression editor since EUIfication of it, and it’s part of the kibana_react plugin in Kibana. I wonder if it makes sense starting some discussion again, around moving EuiCodeEditor over to Monaco?

[snide]

From what I understood, Monaco was hard to use as a side-loaded dependency and that's why we put that component in Kibana directly, rather than EUI. @poffdeluxe can likely fill in the details here.

If that's the case, I think the best thing we can do in EUI is to simply remind people in our docs that the Kibana one exists and point to any docs for it (are there docs?).