Refactoring Markdown lifecycle methods to React 16.3

[markov00]

This PR updates the Markdown component to new React 16.3 lifecycle methods as requested in #17432.

It removes completely the componentWillReceiveProps method in favour of a memoized markdownFactory method. The markdownFactory now use whiteListedRules and openLinksInNewTab as the cache key and return a callable function for rendering a markdown string (avoiding a possible state change of the markdown-it instance).
The memoized function is used by the markdown vis and the tutorial components, so a maximum of 3 instances will coexist on Kibana.

Markdown is now a PureComponent.

[elasticmachine]

💚 Build Succeeded

• continuous-integration/kibana-ci/pull-request

[ppisljar]

the only comment i have is that the new code is harder to read than the old one, looking at the issues you mentioned it seems others are coming to the same conclusion ....

[markov00]

@ppisljar Yes, it's a bit harder to read, and we are duplicating props into state. I can get rid of the initialization of markdown in the constructor since getDerivedStateFromProps is called also before the first rendering, but I've to fix all the markdown_vis tests because of the shallow vs mount issue.

Other possible solutions are:

• use a different markdown library (some of them exists in as pure react implementation)
• memoize the markdownFactory (it doesn't cost too much since we only have openLinksInNewTab that is a boolean and whiteListedRules that is never updated from the editor) create its instance and call the transform method on the render method without passing through setting the state

[elasticmachine]

💚 Build Succeeded

• continuous-integration/kibana-ci/pull-request

[markov00]

@timroes @ppisljar I've updated the PR and the description, can you take a look at the new Markdown refactoring? Seems a bit more readable than the version with the getDerivedStateFromProps.

[timroes]

I would suggest, we just use a pure function component instead inheriting PureComponent here. Functional of course no difference, but I think it reads a bit cleaner and aligns better with what we usually do in components.

[markov00]

I'm using a PureComponent to take advantage of its shallow compare of props. This avoids calling the render method if the parent rerenders and the props aren't changed as opposed to what happens when using a pure function that renders every time its parent renders independently from the props and state.
We have the markdownit render method in the render method of the pure component so it's better to don't rerender everything every time.

[timroes]

I think we should rather return only the rendered markdown from this function, and wrap it in { __html } in the component below. That way the vanilla JS function stays less related to React.

[markov00]

Ok will do ;)

[ppisljar]

LGTM, tested on chrome-linux

[elasticmachine]

💚 Build Succeeded

• continuous-integration/kibana-ci/pull-request

[nreese]

lgtm

code review
tested markdown rendering on home page "add data"

[nreese]

Typo "Rhe" should be "The"

[elasticmachine]

💚 Build Succeeded

• continuous-integration/kibana-ci/pull-request

[elasticmachine]

💚 Build Succeeded

• continuous-integration/kibana-ci/pull-request

[elasticmachine]

💚 Build Succeeded

• continuous-integration/kibana-ci/pull-request

[elasticmachine]

💚 Build Succeeded

• continuous-integration/kibana-ci/pull-request