[EuiMarkdownEditor] Support for a customizable editing experience

[legrego]

Currently, the EuiMarkdownEditor renders the "edit" mode using a plain textarea. This works well for simple Markdown, but it's possible that plugins will want to customize the editing experience by changing the display of the raw Markdown.

For a concrete example, we are looking to support user mentions. The raw markdown might look something like this:

Hey !{user{"id": "abc123dfera"}}, can you check this out?

This is not very friendly to look at, so we would prefer to have the editor show something similar to the following:

Hey larry.gregory, can you check this out?

The replacement text would be treated as a single element, where we could backspace into it to delete the entire reference.

Needed for: elastic/kibana#80334 (8.x timeframe)
(we can make an alternative UX without support for this in EUI, but it will be ugly)

[chandlerprall]

The only piece of this I don't think we'd be able to support at this time is swapping the raw content with a placeholder (!{user{"id": "abc123dfera"}} -> larry.gregory).

The two approaches I think should be explored:

• plugins can define a string|regex|fn that triggers a completion popover (@ -> popup -> @larry.gregory)
• let apps change what component is used for the editor (textarea -> CustomMonacoWrapper), with attention to the API impact

[thomheymann]

I think we need to be careful not to mix different editor styles which would end up being confusing, especially since mentions aren't the only custom embed codes we support.

The EuiMarkdownEditor component currently uses modes: edit and preview. This type of editor should always show the markdown code when in edit mode. We can add syntax highlighting to make mentions and other formatting easier to read but I don't think we should swap out the markdown code with preview content while in edit mode.

Alternatively we could opt for a WYSIWYG editor. This would allow users to format text and add embeddable content without having to toggle between different modes. Users would still be able to type markdown syntax and mentions but it wouldn't actually show the markdown code once applied. Jira and Slack are good examples of this.

In terms of authoring experience WYSIWYG would obviously have a lower barrier of entry but I'm not sure if that's where EuiMarkdownEditor is headed.

Mockups

EuiMarkdownEditor (as is)

I don't think this is a good editing experience since it's quite hard to understand what's going on and it will get messy easily with a few embed codes added, especially once visualisations are involved. I think non-technical users would struggle with this.

EuiMarkdownEditor (with monaco based editor)

I think this is a lot clearer but the JSON syntax is obviously not designed to be human readable like markdown is and non-technical users might still struggle with this a bit.

WYSIWYG editor

I think this is the best editing experience but might involve more effort to build. We could use a rich text editor framework like https://www.slatejs.org or https://draftjs.org.

@chandlerprall Are there any plans to remove modes from EuiMarkdownEditor and turn it into a WYSIWYG editor?
@MichaelMarcialis Do we have designs for mentions? What should the editing experience look like in our collaboration tooling?

[thomheymann]

POC for rich text editor with ability for mentions using Slate.js:

rich-text-autocomplete.mov

POC for syntax highlighting with auto complete using Monaco:

monaco-autocomplete.mov

[chandlerprall]

We have no plans to include a WYSIWYG mode to the editor.

This type of editor should always show the markdown code when in edit mode.

Though I agree that this mode shouldn't show a preview, when I think about bigger configuration blobs like you showed:

I think this is a lot clearer but the JSON syntax is obviously not designed to be human readable like markdown is and non-technical users might still struggle with this a bit.

I wonder if there is a mixed-mode where we show a collapsed version, maybe

- list
- items 

{!lens{...}}

to make it apparent that we've collapsed the markdown, but without rendering the final result either. I think we'd want to visually distinguish that collapsed block further by highlighting, etc, or maybe we could rely on Monaco to fold the blobs up.

The monaco autocomplete POC looks really neat, can you share that project?

[thomheymann]

I wonder if there is a mixed-mode where we show a collapsed version, maybe

- list
- items 

{!lens{...}}

to make it apparent that we've collapsed the markdown, but without rendering the final result either. I think we'd want to visually distinguish that collapsed block further by highlighting, etc, or maybe we could rely on Monaco to fold the blobs up.

Yeh, that's a good idea. Code folding could be implemented using a custom Monaco rule. I don't think it's a solution to the usability issues though, especially since code folding will get confusing when there's multiple elements of the same type being edited. It would be hard to differentiate between them.

It also doesn't solve the problem that mentions use opaque IDs which means users would not be able to see which user is being mentioned.

The monaco autocomplete POC looks really neat, can you share that project?

Yeh, sure, I've created a draft PR here for diff: elastic/kibana#120093
It's implemented using a custom suggestion provider and custom syntax highlighter.

[MichaelMarcialis]

@MichaelMarcialis Do we have designs for mentions? What should the editing experience look like in our collaboration tooling?

I haven't had much involvement with the markdown editor since my time on the Security solution team (when I was designing the original cases UI, nearly two years ago). I imagine either @miukimiu or one of the folks on the @elastic/security-design may have a more up-to-date sense of what they are looking for with regard to mentions in the markdown editor.

[elizabetdev]

@MichaelMarcialis and @thomheymann FYI we created a spec doc (https://docs.google.com/document/d/1nky8AS2a2NZqEcxlpec0gmm4ydMvx4Nx2NjxpL1xViQ/edit#heading=h.28o9qn4prlon) and a discussion #5829 for a new component that will allow mentioning users in EuiMarkdownEditor.

It would be great if you could take a look at the doc. 🙂

[MichaelMarcialis]

@MichaelMarcialis and @thomheymann FYI we created a spec doc (https://docs.google.com/document/d/1nky8AS2a2NZqEcxlpec0gmm4ydMvx4Nx2NjxpL1xViQ/edit#heading=h.28o9qn4prlon) and a discussion #5829 for a new component that will allow mentioning users in EuiMarkdownEditor.

It would be great if you could take a look at the doc. 🙂

Thanks, @miukimiu! I saw that this morning and added a comment to the Google doc with links to our initial wireframes for the upcoming user profile MVP project. I think much of our desired functionality is already accounted for by your spec, but I'd be happy to meet up and compare notes. Let me know.

[github-actions]

👋 Hey there. This issue hasn't had any activity for 180 days. We'll automatically close it if that trend continues for another week. If you feel this issue is still valid and needs attention please let us know with a comment.

[MichaelMarcialis]

Issue still valid.

[elizabetdev]

We explored this feature in a draft PR: #5885.

[github-actions]

👋 Hi there - this issue hasn't had any activity in 6 months. If the EUI team has not explicitly expressed that this is something on our roadmap, it's unlikely that we'll pick this issue up. We would sincerely appreciate a PR/community contribution if this is something that matters to you! If not, and there is no further activity on this issue for another 6 months (i.e. it's stale for over a year), the issue will be auto-closed.

[github-actions]

❌ Per our previous message, this issue is auto-closing after having been open and inactive for a year. If you strongly feel this is still a high-priority issue, or are interested in contributing, please leave a comment or open a new issue linking to this one for context.

[MichaelMarcialis]

Still valid.

[cee-chen]

While this may be valid it's incredibly unlikely that the EUI team will have time to work on this or EuiMarkdownEditor at any point in the future (in fact, our long-term hope is to move the component out of EUI entirely and into Kibana).

Can we circle back to what expectations are for actual work done at some point?

[mdefazio]

Makes sense to me. thank you @cee-chen

[cee-chen]

Re-closing this. EuiMarkdownEditor is already fairly extensible via the plugins that consumers can write themselves and pass in, and we will not be taking on the user mention work described in the issue description. We would encourage Kibana developers who need this functionality to write it in Kibana itself, springboarding off of Chandler's existing spike/investigation in #5885 to do so.