Pass markdown parse results to application

[chandlerprall]

Summary

Added onParse callback to provide stop-the-world error, info messages, and parse results to the consuming application. I've updated the sole markdown example to display this information until we split it up into multiple examples.

Stop-the-world-error

Unified immediately stops all parsing and halts, no parsing result is generated. I've added this to the chart plugin, if you have a malformed JSON configuration object e.g. !{chart{"palette": ,"height":300}}. As another example, I encountered a parsing failure from one of the 3rd party modules, if you use the malformed tag !{tooltip[])}.

If it does fail to parse, the markdown formatter component now renders the markdown string with no processing.

Info messages

Plugins can also generate info messages which do not prevent further parsing. I've given the checkbox plugin 2, one for each of the anchor and tooltip text if no text is provided.

Future

Decisions

We should establish a pattern for what qualifies for info vs failure messages. Traditionally, markdown does not fail - but unified supports the behaviour and we should handle it at least a little gracefully.

Design

If there is a catastrophic stop-the-world error, we probably want to message it in the editor itself.

[kibanamachine]

Preview documentation changes for this PR: https://eui.elastic.co/pr_3602/

[thompsongl]

Code LGTM. The shape of onParse makes sense

[snide]

I think it makes sense for this to be baked into the editor itself rather than through a form row. Reasoning is that we'll likely want the editor to be fullscreen or in composition modes. Thought something simple like this might work?

[chandlerprall]

I think it makes sense for this to be baked into the editor itself rather than through a form row. Reasoning is that we'll likely want the editor to be fullscreen or in composition modes. Thought something simple like this might work?

• the original designs had the help (?) button in that spot; would that still be the case, but be replaced if there are errors?
• in most cases the editor would have line (and column) information and can be formatted as you have in the design, however this is not a guarantee and at times will need to fallback to a plain string
• mind if we move the design/display of this to a separate PR?

[snide]

mind if we move the design/display of this to a separate PR?

Yes. That's fine. Just make sure to add it as a todo to the feature branch PR>

[snide]

Tested functionality. We can handle the design in another PR.

[elizabetdev]

Tested the functionality and it looks good! I left a note to handle the design/display in our feature branch PR todo list.